认识RESTful架构
RESTful API、API、REST
RESTful API
RESTful API 是两个计算机系统用于通过互联网安全地交换信息的接口。大多数业务应用程序必须与其他内部和第三方应用程序进行通信才能执行各种任务。例如，为了生成月度工资单，您的内部账户系统必须与客户的银行系统共享数据才能自动开具发票并与内部工时单应用程序进行通信。RESTful API 支持此类信息交换，因为它们遵循安全、可靠和高效的软件通信标准。
只要API程序遵循了REST风格，那就可以称其为RESTful API。目前在前后端分离的架构中，前后端基本都是通过RESTful API来进行交互。
API
应用程序编程接口（API）定义您与其他软件系统进行通信必须遵循的规则。开发人员公开或创建 API，以便他们的应用程序可以以编程方式与其他应用程序进行通信。例如，工时单应用程序公开一个要求提供员工全名和日期范围的 API。当其收到此信息时，其会对员工的工时单进行内部处理，并返回该日期范围内的工作小时数。
你可以将 Web API 想象为客户端和 Web 上资源之间的大门。
客户端
客户端是要访问 Web 上信息的用户。客户端可以是使用 API 的个人或软件系统。例如，开发人员可以编写从天气系统访问天气数据的程序。或者，您可以在浏览器上直接访问天气网站访问相同的数据。
资源
资源是不同的应用程序向其客户端提供的信息。资源可以是图像、视频、文本、数字或任何类型的数据。向客户端提供资源的设备也称为服务器。企业使用 API 分享资源，既能提供 Web 服务，还能确保安全、可控，身份验证。此外，API 帮助企业确定哪些客户端可以访问特定的内部资源。
REST
表征状态传输 (REST) 是一种软件架构，决定了 API 的工作条件。REST 最初作为管理复杂网络（例如互联网）上的通信的指南而建立。您可以使用基于 REST 的架构为高性能和可靠的大规模通信提供支持。您可以轻松应用和修改此种架构，为任何 API 系统带来可见性和跨平台可能性。
简单来说，REST的含义就是客户端与Web服务器之间进行交互的时候，使用HTTP协议中的4个请求方法代表不同的动作。
GET用来获取资源POST用来新建资源PUT用来更新资源DELETE用来删除资源
为什么要使用 RESTful 架构
RESTful API 有以下优势：
可扩展性
采用了 REST API 的系统可以高效扩展，因为 REST 优化了客户端-服务器交互。无状态可减轻服务器负载，因为服务器不必保留过去的客户端请求信息。管理良好的缓存可部分或完全消除某些客户端-服务器交互。所有这些功能都支持可扩展性，并且不会导致通信瓶颈进而降低性能。
灵活性
RESTful Web 服务支持客户端-服务器完全分离。该服务简化并分离了多种服务器组件，以便可以独立改进每个部分。平台或技术在服务器应用程序端更改，不会影响客户端应用程序。分层应用程序功能可进一步提升灵活性。例如，开发人员可以更改数据库层，而无需重新编写应用程序逻辑。
独立性
REST API 与所使用的技术相互独立。您可以在不影响 API 设计的情况下以多种编程语言编写客户端和服务器应用程序。您也可以在不影响通信的情况下更改任何一端的基础技术。
RESTful API 请求设计
| 请求方法 | URL | 含义 |
|---|---|---|
| GET | /zoos | 列出所有动物园 |
| POST | /zoos | 新建一个动物园 |
| GET | /zoos/:id | 获取某个指定动物园的信息 |
| PUT | /zoos/:id | 更新某个指定动物园的全部信息 |
| PATCH | /zoos/:id | 更新某个指定动物园的部分信息 |
| DELETE | /zoos/:id | 删除某个动物园 |
| GET | /zoos/:id/animals | 列出某个指定动物园的所有动物 |
| DELETE | /zoos/:id/animals/:id | 删除某个指定动物园的指定动物 |
请求 = 动词 + 宾语
- 动词 使用五种 HTTP 方法，对应 CRUD 操作。
- 宾语 URL 应该全部使用名词复数，可以有例外，比如搜索可以使用更加直观的 search 。
- 过滤信息（Filtering） 如果记录数量很多，API应该提供参数，过滤返回结果。
?limit=10指定返回记录的数量?offset=10指定返回记录的开始位置。
RESTful API 响应设计
使用 HTTP 的状态码
- 客户端的每一次请求，服务器都必须给出回应。回应包括 HTTP 状态码和数据两部分。
- 五大类状态码，总共100多种，覆盖了绝大部分可能遇到的情况。每一种状态码都有约定的解释，客户端只需查看状态码，就可以判断出发生了什么情况。API 不需要1xx状态码。
HTTP 状态码分类
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP状态码列表
服务器回应数据
- 客户端请求时，要明确告诉服务器，接受 JSON 格式，请求的 HTTP 头的 ACCEPT 属性要设成
application/json - 服务端返回的数据，不应该是纯文本，而应该是一个 JSON 对象。服务器回应的 HTTP 头的 Content-Type 属性要设为
application/json - 错误处理 如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将 error 作为键名，出错信息作为键值即可。
{error: "Invalid API key"} - 认证 RESTful API 应该是无状态，每个请求应该带有一些认证凭证。推荐使用 JWT 认证，并且使用 SSL
- Hypermedia 即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么
资源参考：
