作为软件开发人员，我们大多数人在日常生活中使用或构建 REST api。API 是系统之间的默认通信方式。亚马逊是如何有效地使用 api 进行通信的最佳例子。
在这篇文章中，我将讨论如何更好地设计 RESTful api 以避免常见错误。
Jeff Bezos’ (成功的关键) 的指令
你们中的一些人可能已经知道Jeff Bezos对亚马逊开发者的授权。如果你没听过，以下几点是它的关键。
- 因此，所有团队都将通过服务接口公开他们的数据和功能。
- 团队之间必须通过这些接口进行沟通。
- 不允许有其他形式的进程间通信，不允许直接链接，不允许直接读取另一个团队的数据存储，不允许共享内存模型，也不允许有后门。唯一允许的通信是通过网络上的服务接口调用。
- 他们使用什么技术并不重要。HTTP 、 Corba 、 Pubsub 、自定义协议都不重要。Bezos不在乎。
- 毫无例外，所有服务接口都必须从头开始设计，才能外部化。也就是说，团队必须进行规划和设计，以便能够向外部世界的开发人员公开接口。没有例外。
- 任何不这样做的人都会被解雇。
最终，这被证明是亚马逊成功的关键。亚马逊可以构建可扩展的系统，之后还可以提供像亚马逊网络服务这样的服务。
RESTful api 的设计原则
现在，让我们来了解在设计 RESTful api 时应该遵循的原则。
保持精简
我们需要确保 API 的基本 URL 是简单的。例如，如果我们想为产品设计 api，它应该是这样设计的:
/products
/products/12345
第一个 API 是获取所有产品，第二个 API 是获取特定产品。
用名词(nouns)而不是动词(verbs)
很多开发者都犯了这个错误。他们通常忘记了我们有 HTTP 方法来更好地描述 API，并最终使用 API url 中的动词。例如，获取所有产品的 API 应该是:
/products
而不是如下所示
/getAllProducts
到目前为止，我已经看到了一些常见的 URL 模式。
使用正确的 HTTP 方法
RESTful API 有各种方法来指示我们将使用此 API 执行的操作类型。
- GET?—?获取资源，请求指定的页面信息，并返回实体主体。
- POST?—?创建资源，向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
- PUT/PATCH?—?更新现有资源，用来对已知资源进行局部更新 。
- DELETE?—?删除现有资源，请求服务器删除指定的页面。
我们需要确保在给定的操作中使用正确的 HTTP 方法。
使用复数
这个话题有点争议。有些人喜欢保留带有复数名称的资源 URL，而另一些人喜欢保留单数。例如-
/products
/product
我喜欢保持它的复数，因为它避免了我们谈论的是获取单个资源还是集合的混淆。它还避免了添加额外的东西，将所有内容附加到基本 URL,比如 /product/all,有些人可能不喜欢这样，但我唯一的建议是在整个项目中保持统一。
使用参数
有时候，我们需要一个 API，它应该比仅仅通过 id 来讲述更多的故事。在这里，我们应该利用查询参数来设计 API。
-
/products?name=’ABC’应该优先考虑/getProductsByName -
/products?type=’xyz’应该优先考虑/getProductsByType
这样，您就可以避免设计简单的长网址。
使用正确的 HTTP 代码
我们有很多 HTTP 代码。我们大多数人最终只使用了两种 200 和 500! 这当然不是一个好的做法。下面是一些常用的 HTTP 代码。
- 200 OK?—?这是显示执行的操作成功的最常用的 HTTP 代码。
- 201 CREATED?—?当您使用 POST 方法创建新资源时，可以使用此方法。
- 202 ACCEPTED?—这可以用来确认发送给服务器的请求。
- 400 BAD REQUEST?—当客户端输入验证失败时，可以使用此方法。
- 401 UNAUTHORIZED / 403 FORBIDDEN— 如果用户或系统无权执行某项操作，则可以使用此选项。
- 404 NOT FOUND— 如果您正在寻找某个资源，并且该资源在系统中不可用，则可以使用该资源。
- 500 INTERNAL SERVER ERROR?—?这永远不应该被明确抛出，但是如果系统失败，可能会发生。
- 502 BAD GATEWAY?—?如果服务器从上游服务器接收到无效响应，则可以使用此选项。
版本控制
Api 的版本控制非常重要。许多不同的公司以不同的方式使用版本。有些使用版本作为日期，有些使用版本作为查询参数。我通常喜欢在资源前面加上它。例如:
/v1/products
/v2/products
我也想避免使用 /v1.2/products, 这意味着 API 会经常变化。此外，在 url 中可能不容易看到点 (.)。所以保持精简。
保持向后兼容性总是一个很好的做法，这样如果你改变 API 版本，消费者就有足够的时间进入下一个版本。
使用分页
当您公开可能返回大量数据的 API 时，必须使用分页，如果没有进行适当的负载平衡，消费者可能最终会关闭服务。我们需要始终记住，API 设计应该是完整的证明和傻瓜证明。
这里建议使用 limit和 offset.例如:, /products?limit=25&offset=50. 还建议保留默认限制和默认偏移。
支持的格式
选择 API 的响应方式也很重要。大多数现代应用程序都应该返回 JSON 响应，除非你有一个仍然需要获得 XML 响应的遗留应用程序。
使用正确的错误信息
保持应用程序发送的一组错误消息并以正确的 id 对其做出响应总是一个很好的做法。例如，如果您使用 Facebook graph APIs，如果出现错误，它会返回如下消息:
{
"error": {
"message": "(#803) Some of the aliases you requested do not exist: products",
"type": "OAuthException",
"code": 803,
"fbtrace_id": "FOXX2AhLh80"
}
}
我还看到了一些例子，在这些例子中，人们返回带有错误消息的 URL，这告诉你更多关于错误消息的信息以及如何处理它。
OpenAPI 规范的使用
为了让你公司的所有团队遵守某些原则，使用 OpenAPI 规范是很有用的。OpenAPI 允许您首先设计 api，并以更简单的方式与消费者分享。
结论：
很明显，如果你想更好地交流，api 是一条路。但是如果它们设计得不好，可能会增加混乱。因此，尽最大努力做好设计，剩下的只是实现。