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中写入一些内容