咱们晓得，两个独自的应用程序须要中介程序能力互相通信。因而，开发人员通常会搭建桥梁（应用程序编程接口），以容许一个零碎拜访另一个零碎的信息或性能。
为了疾速、大规模地集成应用程序，API是应用协定或标准实现的，这些协定或标准定义了通过网络传递的音讯的语义和语法。这些标准组成了API体系结构。
随着工夫的推移，不同的API架构格调曾经公布。 每一种都有本人的标准化数据交换模式，抉择的丰盛引发了对于哪种架构格调是最好的无休止的争执。
明天，许多API消费者称REST为“安眠”，并为GraphQL欢呼，而十年前则相同，REST是取代SOAP的赢家。这些观点的问题在于，他们是全面地抉择一种技术自身，而不是思考它的理论属性和个性如何与以后的状况相匹配。
在本文中，咱们将放弃主观的态度，探讨四大API格调的出场程序，比拟它们的强弱面，并强调它们各自最适宜的场景。
近程过程调用（RPC）：在另一个零碎上调用性能
近程过程调用是一种标准，它容许在不同的上下文中近程执行一个函数。RPC扩大了本地过程调用的概念，但将其放在HTTP API的上下文中。
最后的XML-RPC存在问题，因为确保XML有效载荷的数据类型十分艰难。所以，起初一个RPC API开始应用更具体的JSON-RPC标准，它被认为是比SOAP更简略的替代品。 gRPC是Google在2015年开发的最新RPC版本，gRPC对负载平衡、跟踪、健康检查和认证的反对可插拔，非常适合连贯微服务。
RPC如何工作
客户端调用一个近程过程，将参数和附加信息序列化为音讯，并将音讯发送到服务器。服务器在收到音讯后，对其内容进行反序列化，执行申请的操作，并将后果发回给客户端。服务器存根和客户端存根负责参数的序列化和反序列化。
RPC长处
简略间接的互动。 RPC应用GET来获取信息，并应用POST进行其余所有操作。服务器和客户端之间的交互机制归根结底是调用一个端点并取得响应。
易于增加的性能。 如果咱们对API有了新的需要，咱们能够很容易地增加另一个端点来执行这个需要：
- 编写一个新函数并将其放到一个端点后，
- 当初客户端能够打这个端点，并取得满足设定需要的信息。
高性能。 在提供高性能的网络上，轻量级有效载荷很容易实现，这对于共享服务器和在工作站网络上执行的并行计算十分重要。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将确保这一点。
简略对象拜访协定（SOAP）：使数据作为服务可用
SOAP是一种XML格局的、高度标准化的网络通信协定。 SOAP在Microsoft于XML-RPC发行一年后公布，从中继承了很多货色。 当REST紧随其后时，它们首次并行应用，但很快REST博得了风行度比赛。
SOAP如何工作
XML数据格式背地拖着很多形式化的货色，配合宏大的音讯构造，使得SOAP成为最啰嗦的API格调。
SOAP音讯包含：
- 蕴含申请或响应的注释
- 标头（如果音讯必须确定任何具体要求或额定要求），以及
- 故障告诉在整个申请处理过程中可能产生的任何谬误。
SOAP API逻辑是用Web服务描述语言（WSDL）编写的。这种API描述语言定义了端点，形容了所有能够执行的过程，这使得不同的编程语言和IDE能够疾速建设通信。
SOAP反对有状态和无状态消息传递。在有状态的状况下，服务器存储接管到的信息可能十分沉重。但这对于波及多方和简单交易的操作是正当的。
SOAP长处
与语言和平台无关。创立基于Web的服务的内置性能容许SOAP解决通信并做出与语言和平台无关的响应。
绑定到各种传输协定。SOAP在传输协定方面很灵便，能够适应多种状况。
内置错误处理。SOAP API标准容许返回带有错误代码和解释的重试XML音讯。
许多平安扩大。与WS-Security协定集成后，SOAP能够满足企业级的事务品质。它提供了交易外部的隐衷和完整性，同时容许在音讯层面进行加密。
SOAP毛病
现在，因为多种起因，许多开发人员对必须集成SOAP API的想法感到不安。
仅XML。 SOAP音讯蕴含大量元数据，并且仅反对申请和响应的具体XML构造。
重量级的。 因为XML文件的大小，SOAP服务须要很大的带宽。
广义的专业知识。构建SOAP API服务器须要深刻理解所波及的所有协定及其高度限制的规定。
乏味的音讯更新。 须要额定的致力来增加或删除音讯属性，严格的SOAP模式会减慢采纳速度。
SOAP用例
目前，SOAP架构最常见的是用于企业外部或与其信赖的合作伙伴的集成。
高度平安的数据传输。SOAP严格的构造、平安和受权能力使它成为在API和客户端之间执行正式软件契约的最合适的抉择，同时恪守API提供者和API消费者之间的非法契约。这就是为什么金融组织和其余企业用户抉择SOAP的起因。
REST：使数据可用作资源
REST是一种由一组架构束缚定义的自解释API架构格调，旨在为许多API消费者宽泛采纳。
明天最常见的API格调最后是由Roy Fielding在2000年的博士论文中形容的。REST使服务器端数据可用简略的格局示意，通常是JSON和XML。
REST如何工作
REST并不像SOAP那样严格定义，RESTful架构应该恪守六个架构束缚。
- 对立接口：容许以对立的形式与给定的服务器进行交互，而不思考设施或利用类型。
- 无状态：解决申请的必要状态，就像申请自身所蕴含的那样，服务器不须要存储任何与会话无关的内容。
- 缓存
- 客户端-服务器架构：容许任何一方独立进化
- 应用程序的分层零碎
- 服务器向客户机提供可执行代码的能力
事实上，有些服务只是在肯定水平上是RESTful的。它们以RPC格调为外围，将较大的服务合成为资源，并无效地应用HTTP基础设施。但要害局部是应用超媒体又名HATEOAS，即Hypertext As The Engine of Application State的缩写。基本上，这意味着每一个响应，REST API都会提供元数据，链接到所有对于如何应用API的相干信息。这就是实现客户端和服务器解耦的起因。因而，API提供者和API消费者都能够独立倒退而不障碍他们的交换。
“HATEOAS是REST的一个要害个性。它是真正的REST REST的起因。因为大多数人没有应用HATEOAS，他们实际上是在应用HTTP RPC。”这是Reddit上表白的一些激进意见。事实上，HATEOAS是REST最成熟的版本。然而，要实现这一指标，须要比目前通常应用和构建的API客户端先进得多的智能API是很艰难的。所以，现在即便是十分好的REST API也不肯定能做到。这也是为什么HATEOAS次要作为RESTful API设计的长期倒退愿景。
当一个服务实现了REST的一些性能和RPC的一些性能时，REST和RPC之间的确可能存在一个灰色地带。REST是基于资源或名词，而不是基于动作或动词。
在REST中，应用HTTP办法，如GET、POST、PUT、DELETE、OPTIONS，以及心愿的PATCH，来实现事件。
REST长处
解耦客户端和服务器。尽可能地将客户端和服务器解耦，REST能够实现比RPC更好的形象。一个具备抽象层次的零碎，可能对其细节进行封装，以更好地辨认和维持其属性。这使得REST API具备足够的灵活性，能够随着工夫的推移而倒退，同时放弃一个稳固的零碎。
可发现性。客户端和服务器之间的通信形容了所有，因而不须要内部文档就能了解如何与REST API交互。
缓存敌对。重用了很多HTTP工具，REST是惟一容许在HTTP层面上缓存数据的格调。相比之下，在任何其余API上实现缓存都须要配置一个额定的缓存模块。
反对多种格局。反对多种格局存储和替换数据的能力是目前REST成为构建公共API的支流抉择的起因之一。
REST的毛病
没有独自的REST构造。构建REST API没有确切的正确办法。如何对资源进行建模，对哪些资源进行建模，将取决于每个场景。这使得REST在实践上很简略，但在实践中却很难。
大载荷。REST会返回很多丰盛的元数据，这样客户端就能够仅仅从它的响应中理解利用状态的所有必要信息。对于一个领有大量带宽容量的大型网络管道来说，这种丰盛的元数据并不是什么大问题。但状况并不总是这样，这是Facebook在2012年推出GraphQL格调形容的要害驱动因素。
适度获取和获取有余问题。REST响应蕴含的数据要么太多，要么不够，常常会产生对另一个申请的需要。
REST用例
治理API。最常见的API类型是专一于管理系统中的对象并面向许多使用者的API。REST使此类API具备弱小的可发现性和良好的文档，并且非常适合这种对象模型。
简略的资源驱动型应用程序。REST是连贯不须要灵便查问的资源驱动型利用的贵重办法。
GraphQL：仅查问所需的数据
要调用REST API屡次能力返回所需信息，所以GraphQL的创造是为了扭转游戏规则。
GraphQL是一种形容如何进行准确数据申请的语法。对于具备大量互相援用的简单实体的应用程序数据模型来说，实现GraphQL是值得的。
现在，GraphQL的生态系统正在通过Apollo、GraphiQL和GraphQL Explorer等库和弱小的工具进行扩大。
GraphQL如何工作
GraphQL从构建一个模式开始，它是对你在GraphQL API中可能进行的所有查问以及它们返回的所有类型的形容。构建模式很艰难，因为它须要在模式定义语言(SDL)中应用强类型。
在查问之前有了模式，客户能够依据模式来验证他们的查问，以确保服务器可能响应它。在达到后端利用时，GraphQL操作会针对整个模式进行解释，并与前端利用的数据进行解析。API向服务器发送一个大型查问，返回一个JSON响应，其中蕴含咱们申请的数据的确切形态。
除了RESTful CRUD操作外，GraphQL还有订阅性能，能够从服务器上取得实时告诉。
GraphQL的长处
类型化的模式。GraphQL提前颁布了它能做的事件，这进步了它的可发现性，通过将客户端指向GraphQL API，咱们能够发现有哪些查问。
能很好地适应图形类数据。数据关系很深，但不适宜立体数据。
没有版本控制。版本化的最佳实际是齐全不对API进行版本化。
尽管REST提供了多个API版本，但GraphQL应用的是一个繁多的、一直倒退的版本，能够继续地拜访新的性能，并有助于更洁净、更可保护的服务器代码。
具体的谬误音讯。与SOAP相似，GraphQL提供了产生谬误的细节。它的错误信息包含了所有的解析器，并提到了出错的具体查问局部。
灵便的权限。GraphQL容许有选择地裸露某些性能，同时保留私人信息。同时，REST架构并不显示数据的局部。要么全有，要么全无。
GraphQL的毛病
性能问题。GraphQL以复杂度换取其弱小的性能。在一个申请中领有过多的嵌套字段会导致系统过载。所以，对于简单的查问，REST依然是一个更好的抉择。
缓存简单。因为GraphQL并没有重用HTTP缓存语义，所以须要进行自定义缓存工作。
大量的开发前教育。因为没有足够的工夫来理解GraphQL的小众操作和SDL，许多我的项目决定采纳家喻户晓的REST办法。
GraphQL用例
挪动设施API。在这种状况下，网络性能和单条音讯的有效载荷优化是很重要的。所以，GraphQL为挪动设施提供了更高效的数据加载。
简单的零碎和微服务。GraphQL可能将多个系统集成的复杂性暗藏在其API背地。它从多个中央聚合数据，而后将它们合并到一个全局模式中。这对于传统的基础设施或随着工夫的推移而扩大的第三方API来说，尤其重要。
哪种API模式最适宜您的用例？
每个API我的项目都有不同的要求和需要。通常状况下，架构的抉择取决于：
- 应用的编程语言
- 您正在开发的环境，以及
- 你所领有的资源，包含人力和财力。
理解每一种设计格调的所有衡量，API设计师就能够抉择最适宜我的项目的那一种。
凭借其严密的耦合性，RPC实用于外部微服务，但对于弱小的内部API或API服务来说，它不是一个好抉择。
SOAP尽管麻烦，但其丰盛的平安性能对于计费业务、预订零碎和领取来说，依然是不可代替的。
REST具备API的最高形象和最佳建模。但这往往会减少在线和聊天的累赘——如果您应用的是挪动设施，这是不利的一面。
GraphQL是数据获取方面的一大提高，但并不是每个人都有足够的工夫和精力去把握它。
在一天完结的时候，用一个特定的格调尝试几个小的用例是有意义的，看看它是否适宜你的用例并解决你的问题。如果的确如此，就尝试扩大，看看它是否适宜更多的用例。