RESTful API

RESTful API是一种基于HTTP协议的Web服务接口设计风格。它利用了Web标准的组件，包括HTTP、URL和CRUD（创建、读取、更新、删除）操作，使得API的设计更加标准化和可预测。以下是一些关于如何设计RESTful API的关键原则和最佳实践：

1. 使用标准的HTTP方法：RESTful API使用标准的HTTP方法（如GET、POST、PUT、DELETE等）来执行不同的操作。每个HTTP方法都对应于某种类型的CRUD操作。
2. 使用清晰的URL结构：每个资源都应有一个唯一的URL。例如，要表示一个特定用户的详细信息，可以像这样使用URL：GET /users/{userId}。URL应避免使用会改变状态的动词，如"create"、"update"或"delete"。
3. 使用HTTP状态码：HTTP状态码应准确反映API请求的结果。例如，200表示成功，404表示未找到资源，401表示未授权等。
4. 数据格式：RESTful API通常使用JSON作为数据交换格式。确保API能够处理和返回JSON数据。
5. HATEOAS：HATEOAS（Hypermedia as the Engine of Application State）是一个关键的REST原则，它建议在API响应中包含指向其他相关资源的链接。这有助于客户端自动导航API，并减少客户端和服务器之间的耦合。
6. 版本控制：随着API的发展，可能需要对其进行更改。考虑在URL中使用版本号（如/v1/users），以允许未来的更改而不会破坏现有客户端。
7. 错误处理：确保API能够优雅地处理错误，并在可能的情况下提供有关错误的详细信息。
8. 文档：为API提供详细的文档，包括每个端点的描述、参数、请求和响应的示例，以及任何相关的错误代码。
9. 安全：确保API是安全的，包括对所有请求进行身份验证和授权，并使用HTTPS来保护传输的数据。
10. 可扩展性：设计API时考虑到未来的扩展性。这可能意味着要定义灵活的数据结构，而不是硬编码字段，或者使用分页来限制单个请求返回的数据量。
11. 保持一致性：在API的设计和实现中保持一致性有助于减少客户端的复杂性并提高开发效率。例如，使用相同的方法和URL结构来执行相似的操作。
12. 考虑客户端需求：在设计API时考虑客户端的需求和约束。例如，移动设备可能对数据的大小和传输速度有特定的要求。
13. 测试：确保对API进行充分的测试，包括单元测试、集成测试和端到端测试。这有助于确保API的稳定性和可靠性。
14. 监控和日志记录：实施监控和日志记录，以便跟踪API的性能、错误和流量。这有助于及时发现问题并进行相应的调整。
15. 提供反馈：当客户端或用户遇到问题时，提供有用的反馈信息，以帮助他们快速解决问题。

遵循这些原则和实践可以设计出高效、可靠和可维护的RESTful API。

状态码

我们首先要正确使用各类状态码来表示该请求的处理执行结果。状态码主要分为五大类：

1xx：相关信息
2xx：操作成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误

每一大类有若干小类，状态码的种类比较多，而主要常用状态码罗列在下面：

200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功。
202 Accepted - [*]：表示一个请求已经进入后台排队（异步任务）
204 NO CONTENT - [DELETE]：用户删除数据成功。
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
401 Unauthorized - [*]：表示用户没有权限（令牌、用户名、密码错误）。
403 Forbidden - [*] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
404 NOT FOUND - [*]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。

 

可参考

https://zhuanlan.zhihu.com/p/334809573