为你自己学Go
  • README
  • PART01.Web框架概览
    • 1.01 Web框架概览:学习路线
    • 1.02 Web框架概览-Beego框架分析
    • 1.03 Web框架概览-GIN框架分析
    • 1.04 Web框架概览-Iris框架分析
    • 1.05 Web框架概览-Echo框架分析
  • PART02.Server
    • 2.01 Server详解与面试要点
  • PART03.路由树
    • 3.01 路由树-Beego&GIN&Echo实现与设计总结
    • 3.02 路由树-全静态匹配
    • 3.03 路由树-TDD起步
    • 3.04 路由树-静态匹配测试用例
    • 3.05 路由树-静态匹配之路由查找
    • 3.06 路由树-静态匹配之集成Server
    • 3.07 路由树-通配符匹配之路由注册
    • 3.08 路由树-通配符匹配之路由查找与测试
    • 3.09 路由树-参数路径之基本注册和查找
    • 3.10 路由树-参数路径之校验
    • 3.11 路由树-参数路径之参数值
    • 3.12 路由树-总结与面试要点
  • PART04.课后复习
    • 4.01 课后复习-Server
    • 4.02 课后复习-Route
  • PART05.Context
    • 5.01 Context-简介
    • 5.02 Context-Beego Context设计分析
    • 5.03 Context-Gin Context设计分析
    • 5.04 Context-Echo和Iris的Context设计分析
    • 5.05 Context-处理输入输出总结
    • 5.06 Context-处理输入之Body输入
    • 5.07 Context-处理输入之表单输入
    • 5.08 Context-处理输入之查询参数、路径参数和StringValue
    • 5.09 Context-处理输出
    • 5.10 Context-总结与面试要点
  • PART06.AOP
    • 6.01 AOP简介与不同框架设计概览
    • 6.02 AOP设计方案-Middleware
  • PART07.Middleware
    • 7.01 Middleware-AccessLog
    • 7.02 Middleware-Trace简介和OpenTelemetry
    • 7.03 Middleware-OpenTelemetry测试
    • 7.04 Middleware-OpenTelemetry总结
    • 7.05 Prometheus详解
    • 7.06 Middleware-Prometheus
    • 7.07 Middleware-错误页面
    • 7.08 Middleware-从panic中恢复
    • 7.09 Middleware总结和面试
  • PART08.Review
    • 8.01 课后复习-AOP
    • 8.02 课后复习-Context
    • 8.03 课后复习-Middleware-AccessLog
  • PART09.Appendix
    • 附录1.责任链模式
    • 附录2.生成器模式
    • 附录3.函数选项模式
  • xiaochengxu
    • 01.原力去水印
    • 02.KeePass密码管理：安全轻松的管理您的密码
Powered by GitBook
On this page
  • PART1. Context 处理输入
  • PART2. Context 处理输出
  1. PART05.Context

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

Last updated 9 months ago