Chap.2-The Request-Response Cycle

## 1. 请求对象##
###需求###
虽然通过路由可以建立起URL请求和视图函数的映射关系，在客户端发起请求时调用对应的视图函数（其中路由中的动态变量还可以传递给视图函数），但这还不够。为了让视图函数能够处理客户端发来的请求，它还必须要能够访问客户端发来的数据信息。
###作用###
Flask使用**上下文**中临时的** request**[ (API)][1] 对象向视图函数提供必要的信息，它的作用有：
- 封装客户端发来的 HTTP 请求
- 作为全局可访问的对象，向视图函数统一地提供请求数据
- 得益于上下文，在多线程环境中，Flask可以保证[总会在当前线程上获取正确的数据][4]


##2. 上下文##
###概念###
[@vczh](https://www.zhihu.com/question/26387327/answer/32611575)在知乎回答“什么是上下文”提到：
每一段程序都有很多外部变量。只有像Add这种简单的函数才是没有外部变量的。一旦你的一段程序有了外部变量，这段程序就不完整，不能独立运行。你为了使他们运行，就要给所有的外部变量一个一个写一些值进去。这些值的集合就叫上下文。
从这个角度理解，上下文并非天然存在的，而是类似于某种特定环境。**当你使用了“外部变量”与一个应用或一段程序发生交互，也就产生了相应的上下文；或者说，只有在特定的上下文中，这些“外部变量”才有意义。**

###上下文变量

Flask中存在两种上下文：[应用上下文][2]和[请求上下文][3]，这可以通过相应上下文提供的变量类型来区分判断。
需要注意的是，如上文“请求对象”中所讲，这里的变量都是被封装成对象来使用的。
应用上下文的变量有：
- **current_app** 当前活动应用的实例对象
- **g** 应用在处理请求时用来储存临时信息的对象

请求上下文的变量有：
- **request** 封装了客户端发来的 HTTP 请求的请求对象
- **session** 一个形式为字典的用户会话对象，储存不同请求间需要“记住”的值

###应用状态和上下文的激活###
可以认为，Flask对象在实例化后在模块层次上应用有[两个状态][2]。
第一个状态为“休息”状态，该状态的情况是：
- 目前没处理任何请求
- 可以安全地修改应用对象
- 必须得有一个指向对象的引用来修改它，因为不会有某个神奇的代理变量（
*current_app*）指向你刚创建的或者正在修改的应用对象

当激活一个请求前，应用开始进入“待命”状态，激活上下文：
- 激活应用上下文：
*current_app* 指向实例化的应用对象，线程中开始可以
- 激活请求上下文：
*request* 和 *session* 指向当前的请求

此时，视图函数就可以一边从请求上下文中获取请求，一边从应用上下文中与实例对象进行交互，从而给出正确的响应。





###[请求上下文][3]###
###[代理对象][5]###
需要注意的是，Flask实际提供的

[1]: http://docs.jinkan.org/docs/flask/api.html#id4
[2]: http://docs.jinkan.org/docs/flask/appcontext.html#app-context
[3]: http://docs.jinkan.org/docs/flask/reqcontext.html?highlight=%E8%AF%B7%E6%B1%82%E4%B8%8A%E4%B8%8B%E6%96%87#request-context
[4]: http://docs.jinkan.org/docs/flask/api.html#flask.request
[5]: http://docs.jinkan.org/docs/flask/reqcontext.html#notes-on-proxies