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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://go.sai.show/part05.context/5.05-context-chu-li-shu-ru-shu-chu-zong-jie.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.