架构设计内容分享(二百零二)：API设计,从基础到最佳实践

目录

API设计：电子商务示例

API设计和CRUD：

API范例

REST（表述性状态转移）

GraphQL

gRPC（Google远程过程调用）

API设计中的关系

GET请求的查询、限制和幂等性

向后兼容性和版本控制：

速率限制和CORS

---

API设计：电子商务示例

让我们考虑一个类似Shopify这样的电子商务平台的API。如果你不熟悉Shopify，它是一个著名的电子商务平台，允许企业建立在线商店。

在API设计中，我们关注定义API的输入（比如新产品的产品详情）和输出（比如当某人查询产品时返回的信息）。

 

这意味着我们关注的是接口而不是低级实现。

API设计和CRUD：

因此，焦点主要是定义CRUD操作如何向使用您的电子商务API的用户或系统公开。

CRUD代表Create、Read、Update、Delete。这些是任何数据驱动应用程序的基本操作。

 

例如，要添加新产品（创建），您将通过POST请求发送到/api/products，其中产品详情包含在请求体中。

要检索产品（读取），您需要使用GET请求从/products获取数据。

要更新产品信息（更新），我们使用PUT或PATCH请求到/products/:id，其中id是需要更新的产品的id。

删除类似于更新；我们通过DELETE请求到/products/:id，其中id是需要移除的产品。

通信协议和数据传输机制

另一部分是决定要使用的通信协议，比如HTTP、WebSockets等，以及数据传输机制：JSON、XML或Protocol Buffers。

这适用于RESTful API，但我们还有GraphQL或gRPC范例。

API范例

API有不同的范例，每个范例都有其自己的一套协议和标准。

REST（表述性状态转移）

优势： 无状态：客户端到服务器的每个请求都必须包含理解和完成请求所需的所有信息。使用标准的HTTP方法（GET、POST、PUT、DELETE）。易于被不同客户端（浏览器、移动应用）消费。

缺点： 这可能导致数据的过多或过少获取-因为可能需要更多的端点来访问特定的数据。

特性： 支持分页、过滤（**limit**、**offset**）和排序。使用JSON进行数据交换。

GraphQL

优势： 允许客户端请求确切需要的内容，避免过多或过少获取。基于强类型模式的查询。

缺点： 复杂的查询可能会影响服务器性能。所有请求都以POST请求发送。

特性： 通常以HTTP 200状态码回应，即使在错误的情况下也是如此，并在响应体中提供错误详细信息。

gRPC（Google远程过程调用）

优势： 构建在HTTP/2之上，提供了高级功能，如多路复用和服务器推送。使用Protocol Buffers，一种语言中立、平台中立、可扩展的序列化结构化数据的方式。在带宽和资源方面效率高，特别适用于微服务。

缺点： 与JSON相比，可读性较

差。需要支持HTTP/2。

特性： 支持数据流和双向通信。适用于服务器间通信。

API设计中的关系

在电子商务环境中，您可能会有诸如用户到订单、订单到产品等的关系。

 

设计端点以反映这些关系是重要的。例如，在这种情况下，**GET /users/{userId}/orders**应该为特定用户获取订单。

GET请求的查询、限制和幂等性

常见的查询还包括用于分页的**limit**和**offset**，或者用于在某个日期范围内过滤产品的**startDate**和**endDate**。这允许用户检索特定集合的数据，而不会一次性向系统或用户提供太多信息。

 

设计良好的GET请求是幂等的，这意味着多次调用它不会改变结果。

GET请求永远不应该改变数据。它们只用于检索。

向后兼容性和版本控制：

在修改端点时，保持向后兼容性非常重要。这意味着确保更改不会破坏现有客户端。

版本控制： 引入版本（比如**/v2/products**）是处理重大更改的常见做法。

 

在GraphQL的情况下，添加新字段（v2字段）而不删除旧字段有助于在不破坏现有客户端的情况下发展API。

速率限制和CORS

另一个最佳实践是设置速率限制。这用于控制用户在一定时间内可以发起的请求次数。这对于维护API的可靠性和可用性至关重要。它还防止API受到DDoS攻击。

 

通常做法还包括设置CORS设置（跨域资源共享）。CORS设置对于Web安全至关重要。它们控制哪些域可以访问您的API，防止不希望的跨站点交互。