RESTFUL API：原理，设计和最佳实践
RESTFUL API（表示状态传输API）是一种网络接口设计样式，用于网络应用程序之间的交互。休息是一组建筑原理和约束，而不是标准或协议。当Web服务“恢复”时，它将遵循REST原则，并提供有效，可靠和可扩展的网络服务。 在RESTFUL服务中，每个请求应包含所有必要的信息来处理请求。服务器不应保留有关客户端请求的任何状态信息。 宁静的体系结构可能由多层组成，每个层都执行特定功能。这种结构允许开发更复杂和强大的应用程序。 URI设计 在RESTFUL API设计中，URL（统一资源定位器）通常表示资源（对象），而HTTP方法（例如GET，POST，POST，PUT，DELETE等）表示对这些资源（动词）的操作。这种设计风格强调了资源的状态和代表，而不是行动。 动词 +对象 RESTFUL API中的动词通常是五种HTTP方法，与CRUD操作相对应： 得到： 读 邮政： 创造 放： 更新 修补：更新（通常用于部分更新） 删除： 删除 根据HTTP规范，动词应始终在大写中。 该对象必须是名词 设计API时，URL（统一资源定位器）通常代表用作HTTP动词对象的资源。根据宁静的设计原理，URL应该是名词而不是动词，因为它们代表“资源”集合或一个实例，而不是动作。 不正确的例子： /getAllCars /createNewCar /deleteAllRedCars 这些URL包括动词（例如获取，创建，删除），这些动词描述了动作而不是资源本身。该设计不符合宁静的语义标准。 正确的方法： URL应该专注于描述资源而不是操作。以下是合规URL设计的示例： /users：代表用户的集合 /users/123：代表具有特定ID的单个用户（123） 在上面的示例中， /users 和 /users/123 都是名词，分别代表用户集合和特定的用户资源。这样的URL设计使API易于理解，并与宁静的面向资源的原理保持一致。 通过遵循此命名惯例，我们确保API路径清晰，一致且易于理解和维护。 复数网址 通常建议在URL中使用复数形式以保持一致性和清晰度，因为它们通常代表资源集合。 当您的URL指向资源集合时，请使用复数名词。例如，使用 /users 而不是 /user 代表所有用户的集合。 即使指向一个资源，也建议使用复数形式。例如， /users/123 代表具有ID 123的用户。此方法保持URL一致性。 当资源具有层次关系时，URL应反映该结构。例如， /users/123/posts 可以代表用户123的帖子集合。 避免深度嵌套的网址 一个常见的情况是，当资源需要多个级别的分类时，导致深度嵌套的URL，例如，特定作者检索一定类别的文章： GET […]