web应用框架，或者简单的说是“web 框架”，其实是一种建立web应用的一种方式。从简单的博库系统到复杂的富AJAX应用，web上每个页面都是通过代码来生成的。我发现很多人热衷于学习web框架技术，例如Flask或者Django之类的，但是很多人并不理解什么是web框架，韩剧哦这他们是如何工作的。这篇文章中，我讲探索反复被忽略的web框架基础的话题。阅读完这篇文章，你应该首先对什么是web框架以及他们为什么会存在有更多的认识。这会让你学习一个新的web框架变得简单的多，还会让你在使用不同的框架的时候做个明智的选择。
Web如何工作
在我们讨论框架之前，我们需要理解web如何工作。为此，我们将深入挖掘在浏览器里输入了一个URL按下Enter之后发生了什么。在你的浏览器打开一个新的标签，浏览http://www.jeffkupp.com。我们讨论了显示这个也买你，浏览器都做了什么事情（不关心DNS查询）。
Web服务器
每个页面都以HTML的形式传送到你的浏览器中，HTML是一种浏览器用来描述页面内容和结构的语言。那些负责发送HTML到浏览器的应用称之为“web服务器”，会让你迷惑的是，这些应用运行的机器也通常叫web服务器。
然而，最重要的是要理解，到最后所有的web应用要做的事情是发送HTML到浏览器。不管应用的逻辑多么复杂，最终的结果总是将HTML发送到浏览器(我故意将应用可以相应像JSON或者CSS等不同类型的数据忽略掉，因为在概念上是相同的)。
web应用如何知道发送什么到浏览器呢？它发送浏览器请求的任何东西。
HTTP
浏览器从web服务器(或者叫应用服务器)上使用HTTP协议下载网站，HTTP协议是基于一种请求-响应(request-response)模型的。客户端(你的浏览器)从运行在服务机器上的web应用请求数据，web应用反过来对你的浏览器请求进行响应。
重要的一点是，要记住通信总是由客户端(你的浏览器)发起的，服务器(也就是web服务器)没有办法创建一个链接，发送没有经过请求的数据给你的浏览器。如果你从web服务器上接收到数据，一定是因为你的浏览器显式地发送了请求。
HTTP Method
在HTTP协议中，每条报文都关联方法(method或者verb)，不同的HTTP方法对应客户端可发送逻辑上不同类型的请求，反过来也代表了客户端的不同意图。例如，请求一个web页面的HTML，与提交一个表单在逻辑上是不同的，所以这两种行为就需要使用不同的方法。
HTTP GET
GET方法就像其听起来那样，从web服务器上get(请求)数据。GET请求是目前最常见的一种HTTP请求，在一次GET请求过程中，web应用对请求页面的HTML响应之外，就不需要做任何事情了。特别的，web应用在GET请求的结果中，不应该改变应用的状态(比如，不能基于GET请求创建一个新账号)。正是因为这个原因，GET请求通常认为是安全的，因为他们不会导致应用的改变。
HTTP POST
显然，除了简单的查看页面之外，应该还有更多与网站进行交互的操作。我们也能够向应用发送数据，例如通过表单。为了达到这样的目的，就需要一种不同类型的请求方法：POST。POST请求通常携带由用户输入的数据，web应用收到之后会产生一些行为。通过在表单里输入你的信息登录一个网站，就是POST表单的数据给web应用的。
不同于GET请求，POST请求通常会导致应用状态的改变。在我们的例子中，当表单POST之后，一个新的账户建立。不同于GET请求，POST请求不总是生成一个新的HTML页面发送到客户端，而是客户端使用相应的响应码(response code)来决定应用的操作是否成功。
HTTP Response Codes
通常来说，web服务器返回200响应码，意思是“我已经完成了你要求我做的事情，一切都正常”。响应码总是一个三位数字的代号，web应用在每个响应的同时都发送这样一个代号，表名给定的请求的结果。响应码200字面意思就是”OK”，是响应一个GET请求大多是情况下都适用的代号。然后对于POST请求，可能会有204(“No Content”)发送回来，意思是“一切都正常，但是我不准备向你显示任何东西”。
POST请求仍然会发送一个特殊的URL，这个URL可能和提交数据的页面不同，意识这一点是至关重要的。还是以我们的登录为例，表单可能是在www.foo.com/signup页面，然而点击submit，可能会导致带有表单数据的POST请求发送到www.foo.com/process_signup上。POST请求要发送的位置在表单的HTML中会特别地标明。
web应用
你可以仅仅使用HTTP GET和POST做很多事情。一个应用程序负责接收HTTP请求，同时给HTTP响应，通常包含了请求页面的HTML。POST请求会引起wb应用作出一些行为，可能是往数据库中添加一条记录。还有很多其他的HTTP方法，但是我们目前只关注GET和POST。
那么最简单的web应用时什么样的呢？我们可以写一个应用，让他一直监听80端口(著名的HTTP端口，几乎所有的HTTP都发送到这个端口上)。一旦他接收到等待的客户端发送的请求链接，然后他就会回复一些简单的HTML.
下面是程序代码：
import socket
HOST = '127.0.0.1'
PORT = 80
listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
listen_socket.bind((HOST, PORT))
listen_socket.listen(1)
connection, address = listen_socket.accept()
request = connection.recv(1024)
connection.sendall(b"""HTTP/1.1 200 OK
Content-type: text/html
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
""")
connection.close()这段代码接收简单的链接和简单的请求，不管请求的URL是什么，它都会响应HTTP 200(所以，这不是一个真正意义上的web服务)。content-type:text/html是header字段，header用来提供请求或者响应的元信息。这样，我们就告诉了客户端接下来的数据是HTML。
请求的剖析
如果看一下上面测试程序的HTTP请求，会发现它和HTTP响应非常类似。第一行<HTTP Method> <URL> <HTTP version>，在这个例子中是HTTP/1.1 200 OK。接下来是头部，与请求头头有着相同的格式。最后是响应实际包含的内容。注意，这会被解释为一个字符串或者二进制文件，Content-type头告诉客户端怎么样去解释响应。
web服务器之殇
如果我们继续以上面的例子为基础建立web应用，我们还需要解决很多问题：
1. 怎么检测请求的URL以及返回的正确页面？
2. 处理简单的GET请求之外我们如何处理POST请求？
3. 如何理解更高级的概念，如session和cookie？
4. 如何扩展程序以使其处理上千并发连接？
就像你想的那样，没有人愿意每次建立一个web应用都要解决这些问题。正是这个原因，旧有处理HTTP协议本身和有效解决上面问题的办法的包存在。然而，他们的核心功能和我们的例子是相同的：监听请求，携带一些HTML发回HTTP响应。
解决两大问题： 路由和模板
围绕建立web应用的所有问题中，两个entity尤其突出：
1. 我们如何将请求的URL映射到处理他们的代码上？
2. 我们怎样动态地构造客户端请求的HTML并返回给客户端，这些HTML中带有计算得到的值或者从数据库中去除来的信息。
每个web框架都以某种方法来解决这些问题，也有很不同的解决方案。用例子来说明更容易理解，所以我将针对这些问题讨论Django和Flask的解决方案。但是，首先我们还要简单讨论一下MVC。
Django的MVC
Django充分利用MVC设计模式。MVC，也就是Mode-View-Controller(模型-视图-控制器)，是一种将应用的不同功能从逻辑上划分开。models代表的类似数据库表的资源(与Python中使用class来对真实对象建模使用的方法大体相同)。Controller包含应用的业务逻辑，对model进行操作。为了动态生成HTML，需要view给出所有要动态生成页面HTML的信息。
在Django中优点让人困苦哦的是，Controller被称作view，而view被称为template。除了名字有点怪，Django很好地实现了MVC的体系架构。
Django中的路由
路由是处理请求 URL 到负责生成相关的 HTML 的代码之间映射的过程。在简单的情形下，所有的请求都是有相同的代码来处理（就像我们之前的例子那样）。变得稍微复杂一点，每个 URL 对应一个 view function 。举例来说，如果请求 www.foo.com/bar 这样的 URL，调用 handler_bar() 这样的函数来产生响应。我们可以建立这样的映射表，枚举出我们应用支持的所有 URL 与它们相关的函数。
然而，当 URL 中包含有用的数据，例如资源的 ID（像这样 www.foo.com/users/3/） ，那么这种方法将变得非常臃肿。我们如何将 URL 映射到一个 view 函数，同时如何利用我们想显示 ID 为 3 的用户？
Django 的答案是，将 URL 正则表达式映射到可以带参数的 view 函数。例如，我假设匹配^/users/(?P<id>\d+)/$ 的 URL 调用 display_user(id) 这样的函数，参数 id 是正则表达式中匹配的 id。这种方法，任何/users/<some_number>/这样的 URL 都会映射到 display_user 函数。这些正则表达式可以非常复杂，包含关键字和参数。
Flask 中的路由
Flask 采取了一点不同的方法。将一个函数和请求的 URL 关联起来的标准方法是通过使用 route() 装饰器。下面是 Flask 代码，在功能上和上面正则表达式方法相同：
@app.route('/users/<id:int>/')
def display_user(id):
# ...就像你看到的这样，装饰器使用几乎最简单的正则表达式的形式来将 URL 映射到参数。通过传递给route() 的 URL 中包含的 <name:type> 指令，可以提取到参数。路由像 /info/about_us.html 这样的静态 URL，可以像你预想的这样 @app.route('/info/about_us.html') 处理。
通过Templates生成HTML
继续上面的例子，一旦我们有合适的代码映射到正确的 URL，我们如何动态生成 HTML？对于 Django 和 Flask，答案都是通过 HTML Templating。
HTML Templating 和使用 str.format() 类似：需要动态输出值的地方使用占位符填充，这些占位符后来通过 str.format() 函数用参数替换掉。想象一下，整个 web 页面就是一个字符串，用括号标明动态数据的位置，最后再调用 str.format() 。Django 模板和 Flask 使用的模板引擎 Jinja2 都使用的是这种方法。
然而，不是所有的模板引擎都能相同的功能。Django 支持在模板里基本的编程，而 Jinja2 只能让你执行特定的代码（不是真正意义上的代码，但也差不多）。Jinja2 可以缓存渲染之后的模板，让接下来具有相同参数的请求可以直接从缓存中返回结果，而不是用再次花大力气渲染。
数据库交互
Django 有着“功能齐全”的设计哲学，其中包含了一个 ORM(Object Realational Mapper，对象关系映射)，ORM 的目的有两方面：一是将 Python 的 class 与数据库表建立映射，而是剥离出不同数据库引擎直接的差异。没人喜欢 ORM，因为在不同的域之间映射永远不完美，然而这还在承受范围之内。Django 是功能齐全的，而 Flask 是一个微框架，不包括 ORM，尽管它对 SQLAlchemy 兼容性非常好，SQLAlchemy 是 Django ORM 的最大也是唯一的竞争对手。
内嵌 ORM 让 Django 有能力创建一个功能丰富的 CRUD 应用，从服务器端角度来看，CRUD（Create Read Update Delete）应用非常适合使用 web 框架技术。Django 和 Flask-SQLchemy 可以直接对每个 model 进行不同的 CRUD 操作。
再谈web框架
到现在为止，web 框架的目的应该非常清晰了：向程序员隐藏了处理 HTTP 请求和响应相关的基础代码。至于隐藏多少这取决于不同的框架，Django 和 Flask 走向了两个极端：Django 包括了每种情形，几乎成了它致命的一点；Flask 立足于“微框架”，仅仅实现 web 应用需要的最小功能，其它的不常用的 web 框架任务交由第三方库来完成。
但是最后要记住的是，Python web 框架都以相同的方式工作的：它们接收 HTTP 请求，分派代码，产生 HTML，创建带有内容的 HTTP 响应。事实上，所有主流的服务器端框架都以这种方式工作的（ JavaScript 框架除外）。但愿了解了这些框架的目的，你能够在不同的框架之间选择适合你应用的框架进行开发。
中文原文地址：http://www.cnblogs.com/hazir/p/what_is_web_framework.html
英文原文地址：http://www.jeffknupp.com/blog/2014/03/03/what-is-a-web-framework/
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
