一、概念介绍
1. REST 概念
REST：(Representational State Transfer)即表现层状态转换，定义了资源的通用访问格式，是一种网络应用程序的设计风格和开发方式。
在概念中，需要理解以下几个名称：
资源(Resource)
即服务器上获取到的东西任何资源，一条用户记录，一个用户的密码，一张图片等等都是。
资源的表述(Representation)
即资源格式，是 HTML、XML、JSON、纯文本、图片等等，可以用各种各样的格式来表述你获取到的资源。
状态转移(State Transfer)
即URL定位资源，用 HTTP 动词(GET,POST,DELETE,DETC)描述操作。操作是动词，资源是名词。
统一接口(Uniform Interface)
即通过统一的接口对资源进行操作。
2. REST 特点
REST 通常基于使用 HTTP ， URI ，和 XML 以及 HTML 这些现有的广泛流行的协议和标准，每一种 URI 代表一种资源。
REST 通常使用 JSON 数据格式。
REST 基本架构的四个方法：
GET - 用于获取数据
PUT - 用于更新或添加数据
DELETE - 用于删除数据
POST - 用于添加数据
下面会通过一个场景介绍。
3. REST 优点
可更高效利用缓存来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
二、实例介绍
REST 定义了资源的通用访问格式，接下来一个消费者为实例，介绍 RESTful API 定义：
获取所有 users
GET /api/users
获取指定 id 的 users
GET /api/users/100
新建一条 users 记录
POST /api/users
更新一条 users 记录
PUT /api/users/100
删除一条 users 记录
DELETE /api/users/100
获取一个 users 的所有消费账单
GET /api/users/100/bill
获取一个 user 指定时间的消费账单
GET /api/users/100/bill?from=201910to=201911
以上其中 RESTful 风格 API 几乎包含常见业务情况。
三、Nodejs 实现 RESTful API
1. 初始化 mock 数据
本案例使用 mock 数据来演示，如下：
我们将实现以下 RESTful API ：
2. 获取用户列表
这一步我们会创建 RESTful API 中的 /users，使用 GET 来读取用户的信息列表：
3. 添加用户
这一步我们会创建 RESTful API 中的 /users，使用 POST 来添加用户记录：
4. 获取用户详情
这一步我们在 RESTful API 中的 URI 后面加上 /users/:id，使用 GET 来获取指定用户详情：
=
5. 删除指定用户
这一步我们会创建 RESTful API 中的 /users，使用 DELETE 来删除指定用户：
四、REST 最佳实践
1. URL 设计
1.1 动词 + 宾语的操作指令结构
客户端发出的数据操作指令都是动词 + 宾语的结构。
如上面提到的，GET /user 这个命令，GET 是动词，/user 是宾语。根据 HTTP 规范，动词一律大写。
动词通常有以下五种 HTTP 方法：
GET：读取(Read)
POST：新建(Create)
PUT：更新(Update)
PATCH：更新(Update)，通常是部分更新
DELETE：删除(Delete)
1.2 宾语必须是名词
宾语就是 API 的 URL，是 HTTP 动词作用的对象。它应该是名词，不能是动词。
比如，/users 是正确的，因为 URL 是名词，而下面就都是错误的了：
/getUsers
/createUsers
/deleteUsers
1.3 建议复数 URL
因为 URL 是名词，没有单复数的限制，但是还是建议如果是一个集合，就使用复数形式。如 GET /users 来读取所有用户列表。
1.4 避免多级 URL
避免在多层级资源时，使用多级 URL。常见案例如获取某位用户的购买过的某一类商品:
GET /users/100/product/120
这种 URL 语意不明，也不利拓展，建议只有第一级，其他级别用查询字符串来表达：
GET /users/100?product=120
2. 准确的状态码表示
HTTP 五大类状态码有100多种，每一种状态码都有标准的(或者约定的)解释，客户端只需查看状态码，就可以判断出发生了什么情况，所以服务器应该返回尽可能精确的状态码。
这边列举几个经常使用的状态码介绍：
303 See Other：表示参考另一个 URL。
400 Bad Request：服务器不理解客户端的请求，未做任何处理。
401 Unauthorized：用户未提供身份验证凭据，或者没有通过身份验证。
403 Forbidden：用户通过了身份验证，但是不具有访问资源所需的权限。
404 Not Found：所请求的资源不存在，或不可用。
405 Method Not Allowed：用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内。
410 Gone：所请求的资源已从这个地址转移，不再可用。
415 Unsupported Media Type：客户端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客户端要求返回 XML 格式。
422 Unprocessable Entity：客户端上传的附件无法处理，导致请求失败。
429 Too Many Requests：客户端的请求次数超过限额。
500 Internal Server Error：客户端请求有效，服务器处理时发生了意外。
503 Service Unavailable：服务器无法处理请求，一般用于网站维护状态。
3. 服务端响应
3.1 应该返回 JSON 对象
API 返回的数据格式应该是 JSON 一个对象。
3.2 发生错误时，不要返回 200 状态码
在发生错误时，如果还返回 200 状态码，前端需要解析返回数据才知道错误信息，这样实际上取消了状态码，是不恰当的。
正确的做法应该是在错误时，返回对应错误状态码，并将错误信息返回：
