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. 资源的标识

• 资源是任何可以命名的事物，如用户，评论
• 每个资源可以通过URI唯一标识 https://api/github.com/users https://api/github.com/users/day

2. 表述操作资源

• 客户端不能直接操作服务端资源，通过传 json 操作

3. 自描述信息

• 每个消息（请求或相应）必须提供足够的信息让接受者理解
• 媒体类型（application/json）
• 合理使用 http 方法，get(查)， post(增)，delete(删)等
• 是否缓存： cache-control
• 文字链接用于网页跳转

3.4 REST 设计规范

1. 具体什么样子

• 基本的 URI 格式，如 https://api.github.com/users
• 标准 http 方法，如 get, post, put, patch, delete
• 传输的数据媒体类型，如 JSON

2. 符合 REST 架构风格的 api

• get /users: 获取用户列表
• get /users/day 获取用户详情
• delete users/1 删除 id 为 1 的用户
• put/patch users/1 更新 id 为 1 的用户的信息

“

put 和 patch 的区别：patch 部分更新，put 整体替换

”

3. 响应设计规范

• 查询(后台负责接收参数返回数据)
• 分页（查询的一种），长列表时，优化页面显示，分页返回
• 字段过滤（查询的一种），如果前端不需要的数据可以不用返回，返回指定的字段，减少数据量
• 状态码 200 - 请求成功301 - 资源（网页等）被永久转移到其它URL.404 - 请求的资源（网页等）不存在500 - 内部服务器错误
• 错误处理 输出 JSON 格式错误信息。如果状态码是4xx或者5xx，就应该向用户返回错误信息。一般来说，返回的信息中将 error 作为键名，出错信息作为键值即可
• 安全 https鉴权，有些页面需要先登录才能查看限流，防刷（做个中间层）http 头部加了 limit 字段，记录请求次数，如果超过，报错。也可以提示登录后获得更多的限流值
• 开发者友好 - 提供接口文档

4. 参考资料

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