4 种主流的 API 架构风格对比，java面试高级题目-CSDN博客

本文链接：https://blog.csdn.net/2401_84411718/article/details/137998365

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

不同时间的 API 架构风格，图源：Rob Crowley

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

四种 API 架构风格

1RPC：调用另一个系统的函数

远程过程调用是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念，并将其放在 HTTP API 的上下文中。

最初的 XML-RPC 是存在问题的，因为很难确保 XML 有效负载的数据类型。因此，后来 RPC API 开始使用一个更具体的 JSON-RPC 规范，该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。

另外，分布式、架构系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

RPC 的工作机制

客户端调用一个远程的过程，将参数和附加信息序列化为消息，然后将消息发送到服务端。服务端在接受到消息后，将信息的内容反序列化，执行所请求的操作，然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。

远程过程调用的机制，图源：Guru99

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

SOAP 是一个 XML 格式的、高度标准化的网络通讯协议。在 XML-RPC 发布的一年后，SOAP 由微软发布、并继承了许多 XML-RPC 的特性。在 REST 紧随其后发布，一开始它们是被同时使用，但很快 REST 赢得了这次比赛，成为了更流行的协议。

SOAP 的工作机制

XML 数据格式拖累了很多数据规范。伴随着大量的消息结构，XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。

SOAP 的消息由这些部件组成：

一个 SOAP 消息的例子，图源：IBM

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

SOAP 支持有状态和无状态消息传递。在有状态的情况下，服务器存储接收到的信息可能非常繁琐复杂。但这对于涉及多方和复杂交易的操作是合理的。

SOAP 的优势

独立于语言和平台。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。

绑定到各种协议。SOAP 在适用于多种场景的传输协议方面是十分灵活的。

内置错误处理。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息。

一系列的安全拓展。SOAP 与 ES-Security 集成，因此 SOAP 可满足企业级事务要求。它在事务内部提供了隐私和完整性，同时允许在消息级别进行加密。

SOAP 消息级别的安全性：在标头元素的认证数据以及加密的正文

SOAP 的不足

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

仅使用 XML。SOAP 消息包含大量的元数据，并且在请求和响应时仅支持繁冗的 XML 格式。

重量级。由于 XML 文件的大小，SOAP 服务需要很大的带宽。

非常专业化的知识。构建 SOAP API 服务器需要对所有涉及到的协议以及它们及其严格的限制都有很深的了解。

乏味的消息更新。由于需要额外的工作来添加或者删除某个消息属性，这种死板的 SOAP 模式减慢了其被采用的速度。

SOAP 的用例

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

高度安全的数据传输。SOAP 严格的消息结构，安全性和授权功能使其成为在 API 和客户端之间执行正式软件协议的最合适的选择，同时又符合 API 提供者与 API 使用者之间的法律合同。这就是为什么金融组织和其他企业用户选择适用 SOAP 的原因。

点击关注公众号，Java干货****及时送达

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

REST 如今是一种无需解释的 API 架构风格，它由一系列的架构约束所定义，旨在被广泛 API 使用者采用。

推荐一个 Spring Boot 基础教程及实战示例：https://github.com/javastacks/spring-boot-best-practice

当前最常见的 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 使用者都可以独立发展，而这并不会阻碍他们的交流。

理查森成熟度模型作为实现真正完整且有用的 API 架构的目标。图源：Kristopher Sandoval

“HATEOAS 才是 REST 的关键功能，因为它真正使得 REST 成为 REST。但由于大多数人不使用 HATEOAS，因此他们实际上是在使用 HTTP RPC。”这是 Reddit 上表达的一些激进观点。确实，HATEOAS 是 REST 的最成熟版本。

但是，这非常难以实现，因为这要求 API 客户端要比它们如今构建和使用的方式变得更先进和智能得多。因此，即便是如今非常好的 REST API 也不一定总是能做到这一点。这就是为什么 HATEOAS 主要是作为 RESTful API 设计的长期开发的愿景而存在。

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

以动词为中心的 RPC 模型和以名词为中心的 REST 模型中的操作对比

在 REST 中，使用例如 GET、POST、PUT、DELETE、OPTIONS 可能还有 PATCH 等 HTTP 方法来完成操作。

图源：Thomas David

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 的响应包含的数据会过多或不足，通常会导致客户端需要发送另一个请求。