# 5.05 Context-处理输入输出总结

## PART1. Context 处理输入

处理输入要解决的问题:

* **反序列化输入**: 将Body字节流转换成一个具体的类型
  * 例如将请求体中的一个JSON转化为一个自定义的结构体实例
* **处理表单输入**: 可以看做是一个和JSON或者XML类似的、特殊的序列化方式
* **处理查询参数**: 从URL中的查询参数中读取值,并且转化为对应的类型
* **处理路径参数**: 读取路径参数的值,并转化为具体的类型
* **重复读取Body**: `http.Request.Body`默认只能读取1次,不能重复读取
  * 因此我们自己的WEB框架要考虑封装这个`http.Request.Body`,以支持重复读取
* **读取Header**: 从Header中读取特定的值,并转化为对应的类型
* **模糊读取**: 按照一定的顺序,尝试从Body、Header、路径参数或Cookie中读取值,并转化为特定的类型
  * 有一种观点认为,WEB框架不太应该支持这种功能.因为接口的设计者事前一定是知道一个请求参数到底从哪儿来的(比如他设计了一个RESTful风格的API,那么他的`get`接口就一定带有一个`id`之类的查询参数).如果中间件设计者提供了这种API,那么就意味着允许其使用者作出一个不良的实践.因此WEB框架不太应该支持这种功能.
  * **作为一个设计者(此处的设计者不特指API设计者还是中间件设计者),不要提供模糊的API,而是要提供清晰的API**
  * 在公司设计中间件时,更要注意这一点.因为之所以一帮人组了个团队去上班,除了把功能和页面做出来之外,更重要的是**规范**.如果你提供了这种模糊的API,实际上你就是在**无意间破坏了这种约定**.就像打魔兽世界,野团的raid效率通常是不如公会团的,原因就在于**规范**.

## PART2. Context 处理输出

处理输出要解决的问题:

* **序列化输出**: 按照某种特定的格式输出数据,例如JSON或XML
* **渲染页面**: 要考虑模板路径、命名和渲染的问题
* **处理状态码**: 允许用户返回特定状态码的响应,例如HTTP 404
* **错误页面**: 特定HTTP Status或error的时候,能够重定向到一个错误页面,例如404被重定向到首页
* **设置Cookie**: 设置Cookie的值
* **设置Header**: 往Header中写入一些内容