带着对REST的所有热爱和声明，我们有时会忘记它只是众多选择之一。REST是适用于各种API的非常好的标准，但是对于更细微的场景，还有其他API设计样式。
为了帮助API开发人员了解使用哪种API设计风格以及在何种情况下使用，让我们在其他三个选项（gRPC，GraphQL和Webhooks）的上下文中来看一下REST。我们将在实际中提供REST，GraphQL，gRPC和Webhooks的真实示例，并分析它们的优缺点，以突出说明使每个选项成为理想选择的原因。
REST
REST可能是这一部分中最常见的项目，因为它已在Web API中变得非常普遍。REST是一个概念，最早是由Roy Fielding于2000年在其博士论文中定义的。他使用无状态的设计思想和标准化的方法来构建由一系列针对Web服务的约束所定义的体系结构的基础。蜜蜂。
REST本质上是无状态的，其构建方式使得符合REST的任何Web服务都可以以无状态方式与文本资源表示进行交互。这些操作通常使用GET，POST，PUT和其他HTTP方法来定义，以进行标准化的交互。
REST的主要特性之一是它具有超媒体丰富的事实。实际上，超媒体和REST非常紧密相关，以至于Roy Fielding曾说过，如果API 不支持超媒体，它们在技术上就不是RESTful的。最终，这意味着在REST API中，客户端和服务器之间是松散耦合的，这使客户端和服务器在资源操作方面都具有极大的自由度。因此，可以启用并支持快速迭代，服务器演进，资源供应弹性以及其他此类元素。
REST对我们的支持远不止于此，但它具有分层的体系结构，高效的缓存和高可伸缩性，REST是针对众多问题和约束的高度可发现且高度可变形的解决方案。标准化HTTP语料的价值很难低估，它可以为最终用户提供上下文，并且可以标准化大多数交互。综上所述，REST是现代微服务API行业非常有效，有效且强大的解决方案。
我们可以看到有效的RESTful实现的标志。我们可以在GET中看到一个标准的HTTP verbiage表单，它完全可以执行GET应该执行的操作-检索资源。在这种情况下，URI被很好地定义为“活动”，并且允许指定时区和页面大小的内联请求约束。此外，返回值采用指定的已知的超媒体支持格式。简而言之，这是REST，并且是一个用例的示例，在该用例中，轻量级，无状态的系统正是向终端客户端交付资源所需要的。
gRPC
尽管REST绝对是现代的，但gRPC实际上是对称为RPC或“远程过程调用” 的旧方法的新尝试。RPC是一种在远程服务器上执行过程的方法，有点类似于在距离您的工作站很远的朋友的计算机上运行程序。这有其自身的优点和缺点–实际上，这些缺点是REST开发和实现的关键，实际上，还有诸如SOAP之类的系统固有的其他问题。
gRPC和REST之间的主要区别在于RPC定义其合同协商的方式。REST通过其请求中的标准化术语来定义其交互，而RPC则基于契约的概念起作用，在契约中，协商是由客户端-服务器关系而不是体系结构本身来定义和约束的。RPC将大量的功能（和责任）赋予客户端以执行，同时将许多处理和计算工作转移给托管资源的远程服务器。
因此，RPC在物联网设备和其他需要针对低功率设备进行自定义合约通信的解决方案中非常受欢迎。REST通常被视为对资源的过度需求，而RPC即使在极低功耗的情况下也可以使用。gRPC是RPC概念的进一步发展，并增加了许多功能。
gRPC添加的最大功能是protobufs的概念。Protobuf是用于对数据进行序列化的语言和平台中立的系统，这意味着可以有效地序列化这些通信并以有效的方式进行通信。此外，gRPC具有非常有效且功能强大的身份验证系统，该系统通过Google基于令牌的系统利用SSL / TLS。最后，gRPC也是开源的，这意味着可以对系统进行审核，迭代，派生等等。
有关gRPC的更多信息：探索用于构建微服务的gRPC框架
示例API – Google Cloud，Bugsnag
很难在野外演示gRPC-这主要是由于以下事实：根据gRPC文档本身，gRPC通常用于“最后一英里”。换句话说，gRPC通常是驱动和促进不同服务和API之间通信的最终系统。
但是，gRPC文档指出，由于其可移植性，gRPC被用于移动计算空间以及用于处理来自Google Cloud BigTable Client API，Google Cloud PubSub API和Google Cloud的数据的中介和处理系统。语音API。这是有道理的，因为使用标准传输机制和相对敏捷的数据负载，gRPC可以最好地用于简化，主动和重复的通信。
可以通过稳定性监视服务Bugsnag找到生产中gRPC的另一个示例。Bugsnag工程团队发现，初始设计过程要比RESTful构建更流畅。最终，他们最终发现，由于缺少教程和最佳实践，“开发和测试gRPC的入门门槛很高” 。总体而言，使用gRPC的延迟改进和降低的传输成本使Bugsnag取得了巨大成功。
GraphQL
在这些选项中，GraphQL解决客户-服务器关系的方法是独特的，并且在某种程度上是传统关系的逆转。借助GraphQL，客户端可以确定所需的数据，所需的数据以及所需的格式。这是从服务器到客户端的经典命令的逆转，并允许许多扩展功能。GraphQL与REST和RPC截然不同，REST与REST相比，后者是最重要的体系结构，而RPC由客户端和服务器协商合同，但很大程度上由资源本身定义
应当指出，GraphQL的一个巨大好处是，默认情况下，它通常会提供最小的请求。另一方面，REST通常默认情况下一次发送所有它拥有的所有内容，换句话说，就是最完整的请求。因此，在明确定义了所需数据类型且首选数据量较小的特定用例中，GraphQL可能会更加有用。
话虽如此，但GraphQL的好处往往有些超卖。不再需要版本化的想法源于弃用字段并将其替换为新字段，这就是REST演变所关心的。因此，您不应该认为GraphQL比REST或“下一步”更好，因为它通常是框架化的，而不是REST或“下一步”，而是“客户端和数据之间的新关系”的替代选择。
比较REST，GraphQL，Webhooks和gRPC的用例
正如您可以清楚地看到的那样，这些选项中没有一个比其他选项真正“更好”，而是适合独特的交互方案。我们可以将这些用例总结如下：
REST：一种依赖超媒体的无状态数据传输体系结构。REST可以将可能出于各种目的以各种格式请求的各种资源捆绑在一起。REST从根本上与无状态资源管理有关，因此，在这种情况下最好使用它。需要快速迭代和标准化HTTP语言的系统将发现REST最适合其用途。
gRPC：一个灵活而轻巧的系统，用于请求数据。另一方面，当系统需要一定数量的数据或例行处理，并且请求者的功耗低或资源浪费时，最好使用gRPC。在物联网就是一个很好的例子。
GraphQL：一种方法，其中用户定义期望的数据和该数据的格式。GraphQL来自Facebook，该血统书很好地展示了它的用例-在这种情况下，请求者需要针对特定用途的特定格式的数据。在这些情况下，这些数据格式及其之间的关系至关重要，没有其他解决方案可以提供相同级别的互连数据。
结论
在早期的API开发中，选择设计方法可能是最重要的决定。它既构造了API，又影响了最终用户如何与API本身背后的资源进行交互。换句话说，这不仅是开发人员的选择方法，还是您如何与消费者建立关系的选择。
最终，选择哪种解决方案取决于您的特定用例。每个解决方案都有一个非常特定的目的，因此，说一个解决方案比另一个更好是不公平的。但是，更准确地说，有些解决方案比其他解决方案在执行其核心功能方面更胜一筹-例如，许多RESTful解决方案试图镜像RPC功能的情况。
只有您才能确定哪种解决方案最适合您的代码库。因此，请进行研究并从一开始就选择正确的方法，以获取一些可观的收益。您的代码将更精简，响应更快，并针对当前情况进行量身定制。