编辑“RESTful API”

RESTful [[API]]（Representational State Transfer API）是一种应用程序接口 (API) 的架构风格，旨在通过 [[HTTP]] 请求来访问和操作数据资源。它是基于 REST 的软件设计模式，采用了一组简洁、统一的原则和约束条件，使得不同系统之间的通信更为简单和有效。
== 数据资源 ==
* GET：用于从[[服务器]]检索资源的信息。

* PUT：用于更新服务器上的资源。

* POST：用于在服务器上创建新资源。

* DELETE：用于从服务器删除资源。
== 特点 ==
1、基于 HTTP：利用 HTTP 协议的各种功能，如状态码、头部信息等，实现通信和数据传输。

2、无状态性：每个请求都是独立的，服务器不会保存任何客户端的状态信息，从而提高了系统的可伸缩性和可靠性。

3、资源导向：将数据抽象为资源，每个资源都有一个唯一的标识符，并且可以通过 [[URI]] 进行访问。

4、统一接口：通过统一的 HTTP 方法对资源进行操作，简化了系统的架构和通信过程。

5、轻量级和可扩展：RESTful API 使用标准的 HTTP 协议，具有简单、灵活和可扩展的特点，适用于各种不同规模和类型的应用场景。
== 设计原则 ==
1、资源定位：使用URI（统一资源标识符）来标识资源，通常采用名词来表示资源，如/users表示用户资源集合。

2、直观简洁：接口应该直观且简洁，风格命名保持一致，使得API易于理解和使用。

3、版本化：为了支持上层[[UI]]的灵活性，API必须进行版本化管理，以便于后续的更新和迭代。

4、HTTP方法操作资源：通过HTTP方法如[[GET]]、POST、PUT、DELETE等来操作资源，每种方法对应资源的CRUD（创建、读取、更新、删除）操作。

5、状态码表示结果：使用HTTP状态码来表示操作的结果，如200系列表示成功，400系列表示客户端错误，500系列表示服务器错误。

6、内容协商：支持返回不同的数据格式，通常是[[JSON]]或[[XML]]，这取决于客户端的接受能力和需求。

7、统一接口：确保接口的设计遵循一致性原则，减少不必要的复杂性和学习成本。

8、资源标识：每个资源都应该有一个唯一的URI，便于定位和操作。

9、客户端-服务器分离：客户端和服务器应该是解耦的，服务器不保存客户端的任何状态，每次请求都应包含所有必要的信息。

10、无状态通信：虽然服务器不保存客户端状态，但可以通过诸如[[Cookies]]和[[Session]]等机制在服务器端保持会话状态。
== 工作流程 ==
1、客户端发出HTTP请求：客户端使用HTTP协议向服务器发送请求，包括URI、HTTP方法、请求头等信息。

2、服务器响应HTTP请求：服务器根据请求的URI和HTTP方法，返回相应的HTTP状态码和响应内容。

3、客户端处理响应：客户端根据HTTP状态码和响应内容，处理响应结果。

4、可选的缓存处理：客户端可以缓存响应结果，以便在下一次请求时直接使用缓存结果。

5、重复以上步骤：客户端和服务器可以进行多次请求和响应，以完成整个业务逻辑。  
== 相关条目 ==
* [[API]]
* [[GraphQL]]
* [[SOAP API]]
* [[APIAuto]]
* [[Postman]]