关于java:4-种主流的-API-架构风格对比

作者 | AltexSoft

译者 | 朱琪珊 策动 | 万佳

起源：InfoQ 架构头条（id：ArchFront）

本文探讨了四种次要的 API 架构格调，比拟它们的优缺点，并重点介绍每种状况下最适宜的 API 架构格调。

两个独自的应用程序须要中介程序能力互相通信。因而，开发人员常常须要搭建桥梁——也就是应用程序编程接口（API），来容许一个零碎拜访另一个零碎的信息或性能。

为了疾速、大规模地集成不同的应用程序，API 应用协定或标准来定义那些通过网络传输的音讯的语义和信息。这些标准形成了 API 的体系结构。

在过来，人们曾经公布了多种不同的 API 架构格调。每个架构格调都有它独有的标准化数据交换的模式。这一系列的 API 架构格调的选项，引发了大量的对于哪种架构格调才是最好的争执。

明天，许多 API 的使用者将 REST 称作“沦亡的 REST”（REST in peace），并且为 GraphQL 感到欢欣鼓舞。而十年前，又齐全是另一幅光景：REST 是代替 SOAP 的赢家。这些观点的问题在于，它们的出发点只是为某种技术背书，而不是去思考它理论的属性和个性如何与以后的需要相匹配。

1RPC：调用另一个零碎的函数

近程过程调用是一种容许在不同上下文中近程执行函数的标准。RPC 扩大了本地过程调用的概念，并将其放在 HTTP API 的上下文中。

最后的 XML-RPC 是存在问题的，因为很难确保 XML 无效负载的数据类型。因而，起初 RPC API 开始应用一个更具体的 JSON-RPC 标准，该标准被认为是 SOAP 的更简略的代替计划。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔反对负载平衡、追踪、运行状况检查和身份验证，它非常适合连贯不同的微服务。

RPC 的工作机制

客户端调用一个近程的过程，将参数和附加信息序列化为音讯，而后将音讯发送到服务端。服务端在承受到音讯后，将信息的内容反序列化，执行所申请的操作，而后将后果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。

RPC 的劣势

简略间接的交互。 RPC 应用 GET 来获取信息，应用 POST 来解决其余所有操作。服务端和客户端之间交互的机制归结为调用端点并取得响应。

易于增加新函数。 如果 API 有了新的需要，咱们能够轻松地增加另一个执行这个需要的端点：1）编写一个新函数，并将其放在一个新端点之后；2）当初，客户能够拜访这个端点，并获取合乎其需要的信息。

高性能 。轻量级的无效负载不会对网络产生压力，以此提供高性能，这对于共享服务器和在工作站网络上执行并行计算十分重要。RPC 还可能优化网络层，使得不同服务之间每天发送海量音讯变得十分高效。

RPC 的有余

和底层零碎严密耦合。 API 的形象级别有助于其可重用性。API 与根底零碎的耦合越严密，对其余零碎的可重用性就越差。RPC 与根底零碎的严密耦合不容许其在零碎函数和内部 API 之间建设形象层。这很容易引起平安问题，因为对于根底零碎的细节实现很容易会透露到 API 中。

RPC 的严密耦合使得可伸缩性要求和涣散耦合的团队难以实现。因而，客户端要么会放心调用特定端点的带来的任何可能的副作用，要么须要尝试弄清楚要调用的端点，因为客户端不理解服务器如何命名其函数。

可发现性低。 在 RPC 中，无奈对 API 进行测验总结，或者发送申请来开始了解依据需要应该调用哪个函数。

函数爆炸性增长 。创立新函数非常容易。因而，相较于从新编辑现有的函数，咱们会偏向于创立新的性能，最终产生大量难以了解的、性能重叠的函数。

RPC 的用例

RPC 模式在八十年代开始应用，但这并不意味着它曾经过期了。诸如 Google、Facebook（Apache Thrift）和 Twitch（Twirp）这样的大公司现在正在外部应用高性能的 RPC 版本，来执行极高性能、低开销的消息传递。它们宏大的微服务零碎要求外部通信在应用短消息的状况下也放弃清晰。

命令 API。RPC 是用于将命令发送到近程零碎的正确抉择。例如，Slack API 是十分以命令为核心的：退出频道、来到频道、发送音讯。因而，Slack API 的设计者以相似于 RPC 的款式对其进行了建模，使其玲珑、紧凑并且易于应用。

用于外部微服务的客户特定的 API。因为是在单个提供者和单个使用者之间建设间接的集成，咱们不想像 REST API 那样，花太多工夫通过网络传输大量的元数据。凭借高音讯速率和音讯性能，gRPC 和 Twirp 成为了用于微服务的牢靠用例。通过在底层应用 HTTP 2，gRPC 能优化网络层，使其十分高效地在不同服务之间每天传送大量信息。然而，如果你并不是要着眼于进步网络性能，而是要在公布高度独立的微服务团队之间建设一个稳固的 API 分割。REST 就能做到。

2SOAP：使数据作为服务可用

SOAP 是一个 XML 格局的、高度标准化的网络通讯协定。在 XML-RPC 公布的一年后，SOAP 由微软公布、并继承了许多 XML-RPC 的个性。在 REST 紧随其后公布，一开始它们是被同时应用，但很快 REST 博得了这次较量，成为了更风行的协定。

SOAP 的工作机制

XML 数据格式连累了很多数据标准。随同着大量的音讯构造，XML 数据格式使得 SOAP 成为了最简短的 API 架构格调。

SOAP 的音讯由这些部件组成：

• 一个信封标签：用于开始和完结每条音讯
• 蕴含申请或响应的注释
• 一个标头：用于示意音讯是否由某些标准或额定要求的来确认
• 故障告诉：蕴含了可能在申请处理过程只可能产生的任何谬误

SOAP API 的逻辑由 Web 服务描述语言（WSDL）编写。该 API 描述语言定义了端点并形容了能够执行的所有过程。这使得不同的编程语言和 IDE 可能疾速建设通信。

SOAP 反对有状态和无状态消息传递。在有状态的状况下，服务器存储接管到的信息可能十分繁琐简单。但这对于波及多方和简单交易的操作是正当的。

SOAP 的劣势

独立于语言和平台 。内置创立 Web 服务的性能使得 SOAP 可能解决音讯通信的同时发送独立于语言和平台响应。

绑定到各种协定 。SOAP 在实用于多种场景的传输协定方面是非常灵便的。

内置错误处理 。SOAP API 标准容许返回带有错误码及其阐明的的 XML 重试音讯。

一系列的平安拓展 。SOAP 与 ES-Security 集成，因而 SOAP 可满足企业级事务要求。它在事务外部提供了隐衷和完整性，同时容许在音讯级别进行加密。

SOAP 的有余

现在，因为如下几种起因，许多开发人员在听到必须集成 SOAP API 的想法后都会感到不安。

仅应用 XML。SOAP 音讯蕴含大量的元数据，并且在申请和响应时仅反对繁冗的 XML 格局。

重量级 。因为 XML 文件的大小，SOAP 服务须要很大的带宽。

十分专业化的常识 。构建 SOAP API 服务器须要对所有波及到的协定以及它们及其严格的限度都有很深的理解。

乏味的音讯更新 。因为须要额定的工作来增加或者删除某个音讯属性，这种死板的 SOAP 模式减慢了其被采纳的速度。

SOAP 的用例

目前，SOAP 体系结构最罕用于企业外部或与其信赖的合作伙伴的外部集成。

高度平安的数据传输 。SOAP 严格的音讯构造，安全性和受权性能使其成为在 API 和客户端之间执行正式软件协定的最合适的抉择，同时又合乎 API 提供者与 API 使用者之间的法律合同。这就是为什么金融组织和其余企业用户抉择实用 SOAP 的起因。

3REST：使数据作为资源可用

REST 现在是一种无需解释的 API 架构格调，它由一系列的架构束缚所定义，旨在被宽泛 API 使用者采纳。

以后最常见的 API 架构格调最后时由 Roy Fielding 在其博士论文中提出的。REST 使得服务端的数据可用，并以简略的格局（通常是 JSON 和 XML）来示意它。

REST 的工作机制

REST 的定义并不像 SOAP 那样严格。RESTful 体系结构应该恪守如下六个体系结构束缚：

• 对立接口：无论设施或应用程序类型如何，都能够采纳对立的形式与给定的服务端进行交互。
• 无状态：申请自身蕴含解决该申请所须要的状态，并且服务端不存储与会话相干的任何内容。
• 缓存
• 客户端 – 服务器体系结构：容许单方独立倒退
• 应用程序的层级零碎
• 服务端向客户端提供可执行代码的能力

实际上，某些服务仅在某种程度上是 RESTful 的。而它们的内核采纳了 RPC 款式，将较大的服务合成为资源，并无效地应用 HTTP 根底构造。但 REST 的要害局部是超媒体（又称 HATEOAS），是超文本作为应用程序状态引擎（Hypertext As The Enginer Of Application State）的缩写。

根本来说，这意味着 REST API 在每个响应中都提供元数据，该元数据链接了无关如何应用该 API 的所有相干信息。这样便能够使客户端和服务端解耦。因而，API 提供者和 API 使用者都能够独立倒退，而这并不会妨碍他们的交换。

“HATEOAS 才是 REST 的要害性能，因为它真正使得 REST 成为 REST。但因为大多数人不应用 HATEOAS，因而他们实际上是在应用 HTTP RPC。”这是 Reddit 上表白的一些激进观点。的确，HATEOAS 是 REST 的最成熟版本。

然而，这十分难以实现，因为这要求 API 客户端要比它们现在构建和应用的形式变得更先进和智能得多。因而，即使是现在十分好的 REST API 也不肯定总是能做到这一点。这就是为什么 HATEOAS 次要是作为 RESTful API 设计的长期开发的愿景而存在。

当服务端实现 REST 的某些性能和 RPC 的某些性能时，在 REST 和 RPC 之间的确可能存在这样一个灰色区域。但 REST 是基于资源或名词的，而不是基于动作或动词。

在 REST 中，应用例如 GET、POST、PUT、DELETE、OPTIONS 可能还有 PATCH 等 HTTP 办法来实现操作。

REST 的劣势

客户端和服务端的解耦 ：因为 REST 尽可能地解耦了客户端和服务端，REST 相较于 RPC 能够提供更好的抽象性。具备形象级别的零碎可能封装其实现细节，以更好的标示和维持它的属性。这使得 REST API 足够灵便，能够随着工夫的推移而倒退，同时保持稳定的零碎。

可发现性 ：客户端和服务端之间的通信形容了所有内容，因而不须要内部文档即可理解如何与 REST API 进行交互。

缓存敌对 ：REST 重用了许多 HTTP 工具，也是惟一一种能够在 HTTP 层面上缓存数据的 API 架构格调。与其绝对的是，在任何其余 API 上实现缓存都须要配置其余缓存模块。

多种格局反对 ：REST 领有反对多种格局用于存储和替换数据的能力，这是它现在成为搭建公共 API 的次要抉择的起因之一。

REST 的有余

没有规范的 REST 构造 ：在构建 REST API 方面，没有具体的正确办法。如何对资源进行建模以及哪些资源须要建模取决于不同的状况。这使得 REST 在实践上很简略，但在实践中却很艰难。

宏大的负载： REST 会返回大量丰盛的元数据，以便客户端能够仅从响应中理解无关应用程序状态的所有必要信息。对于具备大量带宽容量的大型网络系统来说，这种“啰嗦”的通信并不算很大的负载。但带宽容量并非总是足够的。这也是 Facebook 在 2012 年提出 GraphQL 架构格调的要害驱动因素。

响应适度和响应有余问题 。REST 的响应蕴含的数据会过多或有余，通常会导致客户端须要发送另一个申请。

REST 的用例

治理 API。在零碎中，专一于治理对象并面向许多使用者的 API 是最常见的 API 类型。REST 帮忙此类 API 具备弱小的可发现性，良好的文档编制，因而 REST 非常适合此对象模型。

简略的资源驱动型应用程序 。在用于连贯不须要查问灵活性的资源驱动型利用时，REST 是一种十分无效的办法。

4GraphQL：仅申请所须要的数据

REST API 须要被屡次调用能力返回所须要的资源。所以，GraphQL 被创造了，并扭转了这所有游戏的规定。

GraphQL 是一种语法，它形容了如何进行准确的数据申请。有些应用程序的数据模型具备许多互相援用的简单实体，在这种状况下，实现 GraphQL 是值得的。

现在，GraphQL 的生态系统正在蓬勃发展，呈现了例如 Apollo、GraphiQL 和 GraphQL Explorer 等弱小的库和工具。

GraphQL 的工作机制

GraphQL 从构建模式（Schema）开始。模式是对于用户能够在 GraphQL API 中进行的所有查问及其返回的所有类型的形容。模式构建十分艰难，因为它须要应用模式定义语言（SDL）进行强类型化。

因为在客户端进行查问之前曾经定义好了模式，所以客户端能够验证其查问语句，以确保服务端可能对查问语句进行响应。在查问语句达到后端应用程序时，GraphQL 操作将依据整个模式进行解释，并向前端应用程序返回解析到的数据。API 向服务端发送一个宏大的查问，该 API 返回一个仅蕴含咱们所需数据的 JSON 响应。

除了蕴含 RESTful 的 CRUD 操作，GraphQL 还有订阅（subscriptions）机制，容许接管来自服务端的实时告诉。

GraphQL 的劣势

具备类型的模式 ：GraphQL 提前公开了它能做什么，从而进步了其可发现性。通过将客户端指向 GraphQL API，咱们能够发现什么查问语句是可用的。

没有版本控制 ：版本控制的最佳实际是不要对 API 进行版本控制。

只管 REST 提供了不同的 API 版本，GraphQL 应用的是不断更新的繁多版本，这使用户能够继续拜访新性能，并有助于提供更整洁、更可保护的服务器代码。

具体的谬误音讯 ：GraphQL 以相似于 SOAP 的形式提供所产生谬误的详细信息。它的谬误音讯包含所有解析器，并指向确切的产生故障时的查问局部。

灵便的权限 ：GraphQL 容许选择性地公开某些性能，同时保留私人信息。而绝对应的是，REST 体系架构不能仅显示局部数据，要么是全副数据，要么是没有数据。

GraphQL 的有余

性能问题 。GraphQL 衡量了复杂性，来实现其弱小性能。一个申请中的嵌套字段太多会导致系统过载。因而，对于简单的查问，REST 依然是更好的抉择。

缓存复杂度 。因为 GraphQL 不再应用 HTTP 缓存语义，因而使用者须要额定自定义缓存。

大量的预开发教育 。因为没有足够的工夫来理解 GraphQL 的某个操作和 SDL，因而许多我的项目决定采纳家喻户晓的 REST 办法。

GraphQL 的用例

挪动 API。在这种状况下，网络性能和单个音讯无效负载优化很重要。因而，GraphQL 为挪动设施提供了更无效的数据加载形式。

简单的零碎和微服务 。GraphQL 可能暗藏其 API 背地的多个系统集成的复杂性。GraphQL 从多个中央聚合数据，并将它们合并为一个全局的模式。对于随时间推移而逐步扩大的遗留基础架构或第三方 API 来说，这尤其重要。

5 哪种 API 模式最实用你的用例？

每个 API 我的项目都有不同的限度和需要。通常，API 架构的抉择取决于：

• 所应用的编程语言，
• 你的开发环境，以及
• 你的资源估算，包含人力资源和财务资源。

在理解了每种设计格调的利与弊之后，API 设计人员能够抉择最适宜我的项目的那一种。

具备强耦合性的 RPC 很实用于外部微服务，但它对外部 API 或者 API 服务而言不是一个好的抉择。

SOAP 的应用有些麻烦，但它弱小的平安拓展使它在计费操作、预订零碎和领取方面是无可替代的。

REST 是针对 API 的最高级别的形象和最佳模型。但它往往会有些“啰嗦”而减少零碎的累赘 —— 如果你应用的是挪动设施，这是个问题。

GraphQL 在数据获取方面向前迈出了一大步，但并不是每个人都有足够的工夫后精力来把握它。

归根结底，去针对一些小型的用例来尝试某种特定 API 架构，并去理解它是否适宜你的用例以及是否解决了你的问题，这样做是比拟适合的。如果它实用于你的用例，就能够尝试扩大并查看它是否实用于更多的用例。

原文链接：

https://levelup.gitconnected….

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)

2. 别在再满屏的 if/ else 了，试试策略模式，真香！！

3. 卧槽！Java 中的 xx ≠ null 是什么新语法？

4.Spring Boot 2.5 重磅公布，光明模式太炸了！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！