Koa入门（一）介绍

1. Koa 简介

koa 是由 Express 原班人马打造的，致力于成为一个更小、更富有表现力、更健壮的 Web 框架。使用 koa 编写 web 应用，通过组合不同的 generator，可以免除重复繁琐的回调函数嵌套，并极大地提升错误处理的效率。koa 不在内核方法中绑定任何中间件，它仅仅提供了一个轻量优雅的函数库，使得编写 Web 应用变得得心应手1.1 更小

koa 体积更小(500多行)、轻量。需要单独下载中间件配合开发。express 内置了很多中间件，集成度高。

1.2 富有表现力

需要编写的代码越少，程序就容易维护和调试。可读性高，编译器和人理解更简单。

1.3 更健壮

容错能力强，异常处理方便，程序不会挂掉，很好地抛异常。

2. 中间件机制

学习 Koa 重点在于理解中间件实现原理，对后续引用第三方库中间件时候有更好了解。

Koa 的应用程序其实就是一个包含一组中间件函数的对象，通过 app.use函数来加载中间件(也有引入顺序要求)，这个函数有两个参数，context 指的是上下文环境对象，封装了一些属性；next 用于把中间件的执行权交给下游的中间件，在当前中间件中位于 next() 之后的代码会暂停执行，直到最后一个中间件执行完毕，再自下而上依次执行每个中间件中 next 值周的代码，类似于栈的先进后出。这种模型被称作“洋葱圈模型”。

简单的理解中间件呢，我觉得就是两边对称，举个例子：有个数组，奇数个也好，偶数个也罢。

const arr = [1, 2, 3, 2, 1]

程序从走向右执行，1 是一个中间件中的代码，同理 2 3。只是在两个 1 中间有个 next() 指向 2，2 中有个 next() 指向 3。但是 next() 执行完后还会回到当前的中间件（不知道是否解释清了，还是更乱了😂）

代码实现如下：

后面会详细介绍，大家先了解
// #1
app.use(async (ctx, next)=>{
    console.log(1)
    await next();
    console.log(1)
});
// #2
app.use(async (ctx, next) => {
    console.log(2)
    await next();
    console.log(2)
})

app.use(async (ctx, next) => {
    console.log(3)
})

3. REST

3.1 介绍

REST 是一种风格，是个万维网软件架构的风格，用于创建网络服务。REST 不是指休息的意思，而是 Representational State Transfer 的缩写，即 —— 表现层状态转化。

• 表现层 把资源具体呈现出来的形式，比如文本可以用txt格式表现，也可以使用JSON格式、二进制格式表现。
• 状态 指的当前状态，状态可以改变，使用 put 修改，使用 delete 删除等。
• 转化 通过 http 协议，在客户端和服务端进行数据传输。

3.2 REST的6个限制

• 客户-服务器（Client-Server）（CS架构）
  • 关注点分离：服务端专注于数据处理，增删改查；客户端专注页面的交互和用户体验。
  • 简单性： 原来的服务端还需要渲染页面，MVC 模式，现在只需要关注数据，减少代码量
  • 可移植性：页面可以方便的移到其他平台，一套代码，接口不变就没问题。
• 无状态（Stateless）
  • 简单性：所有用户会话信息（用户信息）都保存在客户端，存在本地缓存。不需要由服务端存储记录
  • 可见性：客户端每次请求必须包括所有信息，不能依赖上下文信息
  • 可靠性：前后端完全依靠接口，比较独立，系统稳定
• 缓存（Cache）
  • 所有服务端响应都要被标为可缓存或不可缓存（cache-control）
  • 减少前后端交互，提升了性能(js 文件，css 文件都可以本地缓存)
• 统一接口（Uniform Interface）
  • 接口设计尽可能统一通用，提升了简单性、可见性（简单、易学、易维护）
  • 接口与实现解耦，使前后端可以独立开发迭代（开发人员不用在一块，有电脑依靠文档就可以实现快速开发）
• 分层系统（Layered System）
  • 每层只知道相邻的一层，后面隐藏的就不知道了（前端只知道接口，不了解后面可能存在的代理服务器）
  • 其它层：安全性、负载均衡（流量分发）、缓存层等
• 按需代码（Code - On - Demand 可选）
  • 客户端可以下载运行服务器传来的代码（比如 js，使用 eval 执行）
  • 常用的不会变的代码放在服务器，减少一些功能，简化了客户端

3.3 统一接口子限制

1. 资源的标识
2. 资源是任何可以命名的事物，如用户，评论
3. 每个资源可以通过URI唯一标识 https://api/github.com/users https://api/github.com/users/day
4. 表述操作资源
5. 客户端不能直接操作服务端资源，通过传 json 操作
6. 自描述信息
7. 每个消息（请求或相应）必须提供足够的信息让接受者理解
8. 媒体类型（application/json）
9. 合理使用 http 方法，get(查)， post(增)，delete(删)等
10. 是否缓存： cache-control
11. 文字链接用于网页跳转

3.4 REST 设计规范

1. 具体什么样子
2. 基本的 URI 格式，如 https://api.github.com/users
3. 标准 http 方法，如 get, post, put, patch, delete
4. 传输的数据媒体类型，如 JSON
5. 符合 REST 架构风格的 api
6. get /users: 获取用户列表
7. get /users/day 获取用户详情
8. delete users/1 删除 id 为 1 的用户
9. put/patch users/1 更新 id 为 1 的用户的信息put 和 patch 的区别：patch 部分更新，put 整体替换
10. 响应设计规范
11. 查询(后台负责接收参数返回数据)
12. 分页（查询的一种），长列表时，优化页面显示，分页返回
13. 字段过滤（查询的一种），如果前端不需要的数据可以不用返回，返回指定的字段，减少数据量
14. 状态码
    • 200 - 请求成功
    • 301 - 资源（网页等）被永久转移到其它URL.
    • 404 - 请求的资源（网页等）不存在
    • 500 - 内部服务器错误

• 错误处理
  • 输出 JSON 格式错误信息。如果状态码是4xx或者5xx，就应该向用户返回错误信息。一般来说，返回的信息中将 error 作为键名，出错信息作为键值即可
• 安全 - https - 鉴权，有些页面需要先登录才能查看 - 限流，防刷（做个中间层）http 头部加了 limit 字段，记录请求次数，如果超过，报错。也可以提示登录后获得更多的限流值
• 开发者友好 - 提供接口文档

4. 参考资料

• 理解RESTful架构
• Node.js开发仿知乎服务端 深入理解RESTful API