API怎么选？比较SOAP，REST，GraphQL和RPC _API

文章插图
两个独立的应用程序需要中介程序才能相互通信。因此，开发人员经常建立桥梁-应用程序编程接口-来允许一个系统访问另一个系统的信息或功能。
为了快速，大规模地集成应用程序，使用协议和/或规范来定义通过导线传递的消息的语义和语法的API 。这些规范构成了API体系结构。
随着时间的流逝，已经发布了不同的API架构样式。它们每个都有自己的标准化数据交换模式。选择的余地引发了关于哪种建筑风格最好的争论。

文章插图
> API styles over time, Source: Rob Crowley
如今，许多API使用者将REST称为" REST和平"，并为GraphQL欢呼，而十年前，REST取代SOAP成为赢家，这是一个相反的故事。这些观点的问题在于，他们只是一方面选择一种技术，而不是考虑其实际属性和特性如何与当前情况相匹配。
【API怎么选？比较SOAP，REST，GraphQL和RPC】在本文中，我们将保持客观，并按外观顺序讨论四种主要的API样式，比较它们的优缺点，并重点介绍每种情况下最适合的情况。

文章插图
> Four major API styles compared
远程过程调用（RPC）：在另一个系统上调用功能远程过程调用是一种允许在不同上下文中远程执行功能的规范。RPC扩展了本地过程调用的概念，但将其放在HTTP API的上下文中。
最初的XML-RPC存在问题，因为很难确保XML有效负载的数据类型。因此，后来RPC API开始使用更具体的JSON-RPC规范，该规范被认为是SOAP的更简单替代方案。gRPC是google在2015年开发的最新RPC版本。gRPC可插拔支持负载平衡，跟踪，运行状况检查和身份验证，非常适合连接微服务。
RPC如何运作客户端调用远程过程，将参数和其他信息序列化为消息，然后将消息发送到服务器。在接收到消息时，服务器反序列化其内容，执行所请求的操作，然后将结果发送回客户端。服务器存根和客户端存根负责参数的序列化和反序列化。

文章插图
> Remote Procedure Calling Mechanism, Source: Guru99
RPC优点简单直接的互动。RPC使用GET来获取信息，并使用POST进行其他所有操作。服务器与客户端之间的交互机制归结为调用端点并获得响应。
易于添加的功能。如果对API提出了新要求，我们可以轻松添加另一个执行此要求的端点：1）编写一个新函数并将其扔到端点后面； 2）现在，客户可以访问该端点并获取符合设置要求的信息。
高性能。轻量级有效负载在网络上变得容易，可提供高性能，这对于共享服务器和在工作站网络上执行的并行计算非常重要。RPC能够优化网络层，并通过每天在不同服务之间发送大量消息来使其变得非常高效。
RPC缺点与底层系统紧密耦合。API的抽象级别有助于其可重用性。它与基础系统越紧密，对其他系统的可重用性就越差。RPC与基础系统的紧密耦合不允许在系统功能和外部API之间建立抽象层。这很容易引起安全问题，因为很容易将有关基础系统的实施细节泄漏到API中。RPC的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此，客户端要么担心调用特定端点的任何可能的副作用，要么尝试弄清楚要调用的端点，因为它不了解服务器如何命名其功能。
发现性低。在RPC中，无法对API进行自省或发送请求，也无法根据其请求开始理解要调用的函数。
功能爆炸。创建新功能非常容易。因此，我们不用编辑现有功能，而是创建新功能，最后添加大量难以理解的重叠功能。
RPC用例RPC模式在80年代左右开始使用，但这并不会自动使其过时。诸如Google，Facebook（Apache Thrift）和Twitch（Twirp）之类的大公司正在内部使用RPC高性能变量来执行非常高性能，低开销的消息传递。他们庞大的微服务系统要求内部通信在安排短消息时保持清晰。
命令API 。RPC是将命令发送到远程系统的正确选择。例如，Slack API非常注重命令：加入频道，离开频道，发送消息。因此，Slack API的设计人员以类似于RPC的样式对其进行了建模，使其小巧，紧凑且易于使用。
内部微服务的客户特定API 。由于在单个提供商和使用者之间进行了直接集成，我们不想像REST API那样花费大量时间通过网络传输大量元数据。凭借高消息速率和消息性能，gRPC和Twirp是微服务的强大案例。在后台使用HTTP 2，gRPC能够优化网络层并使其非常高效，每天在不同服务之间发送大量消息。但是，如果您不是要着眼于提高网络性能，而是要在发布高度独特的微服务的团队之间建立稳定的API联系，REST将确保这一点。