什么是web框架？web框架工作原理解剖

我们常用的web前端框架 其实简单称呼叫web框架，现阶段web前端技术成熟，从视觉体验到用户体验都是比较好的，这也是从简单到复杂的web前端框架技术实现的，在国内前端技术开发人员也是非常的多，市面上的前端框架可以说是眼花缭乱，这里写这篇文章就是让你在使用不同的前端框架 的时候能够明确的知道自己的选择。

Web前端框架工作原理：

在我们讨论框架之前，我们需要理解Web如何“工作”的。为此，我们将深入挖掘你在浏览器里输入一个URL按下Enter之后都发生了什么。在你的浏览器中打开一个新的标签，浏览http://www.uileader.com。我们讨论为了显示这个页面，浏览器都做了什么事情（不关心DNS查询）。

Web服务器

每个页面都以HTML的形式传送到你的浏览器中，HTML是一种浏览器用来描述页面内容和结构的语言。那些负责发送HTML到浏览器的应用称之为“Web服务器”，会让你迷惑的是，这些应用运行的机器通常也叫做web服务器。

然而，最重要的是要理解，到最后所有的web应用要做的事情就是发送HTML到浏览器。不管应用的逻辑多么复杂，最终的结果总是将HTML发送到浏览器（我故意将应用可以响应像JSON或者CSS等不同类型的数据忽略掉，因为在概念上是相同的）。

HTTP

浏览器从web服务器（或者叫应用服务器）上使用HTTP协议下载网站，HTTP协议是基于一种 请求-响应（request-response）模型的。客户端（你的浏览器）从运行在物理机器上的web应用请求数据，web应用反过来对你的浏览器请求进行响应。

重要的一点是，要记住通信总是由客户端（你的浏览器）发起的，服务器（也就是web服务器）没有办法创建一个链接，发送没有经过请求的数据给你的浏览器。如果你从web服务器上接收到数据，一定是因为你的浏览器显示地发送了请求。

HTTP Methods

在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）来决定对应用的操作是否成功。

HTTTP Response Codes

通常来说，web服务器返回200的响应码，意思是，“我已经完成了你要求我做的事情，一切都正常”。响应码总是一个三位数字的代号，web应用在每个响应的同时都发送一个这样的代号，表明给定的请求的结果。响应码200字面意思是“OK”，是响应一个GET请求大多情况下都使用的代号。然而对于POST请求， 可能会有204（“No Content”）发送回来，意思是“一切都正常，但是我不准备向你显示任何东西”。

Web应用

你可以仅仅使用HTTP GET和POST做很多事情。一个应用程序负责去接收一个HTTP请求，同时给以HTTP响应，通常包含了请求页面的HTML。POST请求会引起web应用做出一些行为，可能是往数据库中添加一条记录这样的。还有很多其它的HTTP方法，但是我们目前只关注GET和POST。

那么最简单的web应用是什么样的呢？我们可以写一个应用，让它一直监听80端口（著名的HTTP端口，几乎所有HTTP都发送到这个端口上）。一旦它接收到等待的客户端发送的请求连接，然后它就会回复一些简单的HTML。

下面是程序的代码：

import socketHOST = ''PORT = 80listen_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 OKContent-type: text/html

（如果上面的代码不工作，试着将PORT改为类似8080这样的端口。）

这个代码接收简单的链接和简单的请求，不管请求的URL是什么，它都会响应HTTP 200（所以，这不是一个真正意义上的web服务器）。Content-type:text/html行代码的是header字段，header用来提供请求或者响应的元信息。这样，我们就告诉了客户端接下来的数据是HTML。

请求的剖析

如果看一下测试上面程序的HTTP请求，你会发现它和HTTP响应非常类似。第一行 ，在这个例子中是GET / HTTP/1.0。第一行之后就是一些类似Accept: */*这样的头（意思是我们希望在响应中接收任何内容）。

我们响应和请求有着类似的第一行，格式是 ，在外面的例子中是HTTP/1.1 200 OK。接下来是头部，与请求的头部有着相同的格式。最后是响应的实际包含的内容。注意，这会被解释为一个字符串或者二进制文件，Content-type头告诉客户端怎样去解释响应。

解决路由和模板两大问题

围绕建立web应用的所有问题中，两个问题尤其突出：

1.我们如何将请求的URL映射到处理它的代码上？

2.我们怎样动态地构造请求的HTML返回给客户端，HTML中带有计算得到的值或者从数据库中取出来的信息？

每个web框架都以某种方法来解决这些问题，也有很多不同的解决方案。用例子来说明更容易理解，所以我将针对这些问题讨论Django和Flask的解决方案。但是，首先我们还需要简单讨论一下MVC。

Django中的MVC

Django充分利用MVC设计模式。MVC，也就是Model-View-Controller（模型-视图-控制器），是一种将应用的不同功能从逻辑上划分开。models代表的是类似数据库表的资源（与Python中用class来对真实世界目标建模使用的方法大体相同）。controls包括应用的业务逻辑，对models进行操作。为了动态生成代表页面的HTML，需要views给出所有要动态生成页面的HTML的信息。

在Django中有点让人困惑的是，controllers被称做views，而views被称为templates。除了名字上的有点奇怪，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\d+)/$的URL调用display_user(id)这样的函数，这儿参数id是正则表达式中匹配的id。这种方法，任何/users//这样的URL都会映射到display_user函数。这些正则表达式可以非常复杂，包含关键字和参数。

Flask中的路由

Flask采取了一点不同的方法。将一个函数和请求的URL关联起来的标准方法是通过使用route()装饰器。下面是Flask代码，在功能上和上面正则表达式方法相同：

@app.route('/users//')

def display_user(id):

# ...

就像你看到的这样，装饰器使用几乎最简单的正则表达式的形式来将URL映射到参数。通过传递给route()的URL中包含的指令，可以提取到参数。路由像/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（CreateRead Update Delete）应用非常适合使用web框架技术。Django和Flask-SQLchemy可以直接对每个model进行不同的CRUD操作。

总结：

到现在为止，web前端框架的目的应该非常清晰了：向程序员隐藏了处理HTTP请求和响应相关的基础代码。至于隐藏多少这取决于不同的框架，Django和Flask走向了两个极端：Django包括了每种情形，几乎成了它致命的一点；Flask立足于“微框架”，仅仅实现web应用需要的最小功能，其它的不常用的web框架任务交由第三方库来完成。

但是最后要记住的是，Python web框架都以相同的方式工作的：它们接收HTTP请求，分派代码，产生HTML，创建带有内容的HTTP响应。事实上，所有主流的服务器端框架都以这种方式工作的（JavaScript框架除外）。但愿了解了这些框架的目的，你能够在不同的框架之间选择适合你应用的框架进行开发。