六种流行的API架构风格

大家好，我是猿java。

作为一名 Java程序员，编写业务 API是非常日常的开发工作，那么，如何选择合适的 API框架？今天我们就来一起聊聊当下最流行的六种API架构风格。

一、SOAP 

定义

SOAP，Simple Object Access Protocol，中文翻译为：简单对象访问协议。它是一种基于 XML用于在网络上进行交互的通信协议，旨在支持分布式计算环境中的应用程序之间的通信。

原理

SOAP的工作原理如下：

• XML格式：SOAP使用 XML作为消息格式，将传输的数据封装在 XML结构中，以便在网络上传输。XML提供了一种通用的、可扩展的数据格式，易于解析和处理。
• 消息结构：SOAP消息由一个envelope（信封）元素组成，其中包含一个header（头）元素和一个body（正文）元素。header可用于携带与消息处理相关的元数据，而body则包含实际的数据内容。
• 协议绑定：SOAP可以通过不同的协议进行传输，如HTTP、SMTP等。协议绑定指定了在使用特定协议时如何打包、编码和传输SOAP消息。
• 交互模式：SOAP支持不同的交互模式，包括请求/响应模式、单向模式和异步模式。在请求/响应模式下，客户端发送一个SOAP请求消息给服务端，服务端处理请求并返回一个SOAP响应消息。单向模式只涉及单向消息传递，而异步模式允许客户端和服务端在不同的时间处理消息。
• 服务描述：SOAP使用WSDL（Web Services Description Language）来描述提供的服务。WSDL定义了服务的接口、消息格式、协议绑定等信息，使得客户端能够了解和使用服务。
• 消息交换：客户端通过构建一个符合SOAP协议的XML消息，并将其发送到服务端的URL上。服务端接收到消息后解析、处理并生成相应的响应消息。消息的交换是基于协议规范和约定的。

SOAP的设计目标是提供一种标准化的、可互操作的方式，使得不同平台上的应用程序能够进行通信和交互。它被广泛用于Web服务中，作为一种用于跨网络进行通信的协议。

使用场景

SOAP 在早期的 Web服务领域中广泛应用，现如今，SOAP在一些情况下已被 RESTful API 和其他轻量级协议所取代，不过 SOAP 仍然有一些适合的使用场景：

• 企业级应用程序集成：SOAP在企业环境中的应用非常广泛，特别适用于不同平台和技术栈之间的应用程序集成。它提供了强大的工具和标准，使得不同系统之间的通信变得可靠且可互操作。
• 分布式系统：当构建分布式系统时，SOAP可以提供一种跨网络的通信方式。它提供了结构化的消息格式和强大的类型系统，使得在分布式环境中的服务之间进行通信更加可靠和准确。
• 安全性要求高的场景：SOAP支持通过使用WS-Security协议来提供消息级别的安全性。它可以提供消息的加密、数字签名、身份验证和授权等安全功能，使得在安全性要求高的场景下，如金融、医疗等领域，使用SOAP更具优势。
• 强类型数据传输：SOAP使用 XML作为消息格式，XML具有自我描述和可扩展的特性，因此适合在需要传输复杂结构化数据的场景中使用。通过使用 XML Schema来定义消息结构，SOAP可以提供强类型的数据传输。
• 既有的Web服务：在一些早期的Web服务中，特别是那些使用 SOAP和 WSDL进行描述的服务，仍然在生产环境中运行。在这些情况下，使用 SOAP是为了与现有的服务进行兼容和互操作。

需要注意的是，SOAP 相对于 RESTful API来说，更加重量级，使用起来可能更复杂。在现代的 Web开发中，RESTful API通常更受欢迎，因为它们更简洁、轻量级和易于使用。然而，在特定的场景下，如企业级集成和安全性要求高的系统，SOAP仍然是一种有价值的选择。

示例

(1) 定义 SOAP 消息结构

(2) 定义客户端

(3) 定义服务端

示例演示了如何发送 SOAP 请求消息并在服务器端处理请求并返回响应消息。具体实现可能因编程语言、平台和使用的 SOAP 库而有所不同。在实际应用中，还可以使用 WSDL（Web Services Description Language）来定义 SOAP 消息的结构和服务接口。

二、RESTful 

定义

RESTful，Representational State Transfer，中文翻译为：代表性状态转移。它是一种基于现有 Web标准和 HTTP协议的设计和构建网络应用程序的架构风格，旨在提供一种简洁、可扩展、可靠和可互操作的方式来进行网络通信。

原理

RESTful的原理如下：

• 资源（Resources）：RESTful架构将应用程序的功能和数据抽象为资源。资源可以是任何事物，如用户、产品、订单等。每个资源通过唯一的标识符（URI）进行访问和操作。
• 统一接口（Uniform Interface）：RESTful使用统一的接口进行资源的操作。这个接口通常包括HTTP动词（GET、POST、PUT、DELETE等）和资源的URI。通过不同的HTTP动词和URI的组合，可以对资源进行不同的操作，如获取资源、创建资源、更新资源和删除资源等。
• 状态转移（State Transfer）：RESTful强调资源的状态转移，即客户端通过请求对资源进行状态的改变。客户端发送的请求应包含足够的信息来描述所需的操作，并且服务端的响应应包含足够的信息来反映资源的状态变化。
• 无状态（Stateless）：RESTful是无状态的，意味着每个请求都是独立的，服务端不会存储客户端的状态信息。客户端在每个请求中包含所有必要的信息，而服务端仅依赖于请求本身来处理和响应。
• 可缓存（Cacheable）：RESTful支持缓存机制，以提高性能和减少网络流量。服务端可以通过在响应中添加适当的缓存标识（如ETag、Last-Modified等）来指示客户端对资源的缓存。
• 分层系统（Layered System）：RESTful支持系统的分层结构，允许通过中间层来实现负载均衡、安全性、缓存等功能。客户端无需知道和关心系统内部的层次结构，只需通过统一接口与资源进行交互。

RESTful架构的设计目标是提供一种简单、灵活、可扩展和可重用的方式来构建网络应用程序。它具有与HTTP协议的天然集成和基于标准化接口的优势，因此成为了Web服务和API设计的常用架构风格。

使用场景

RESTful 的使用场景包括以下几个方面：

• Web服务：RESTful是设计和实现Web服务的一种常用方式。它利用HTTP协议的GET、POST、PUT、DELETE等方法来进行资源的创建、读取、更新和删除操作，使得不同平台和技术栈的应用程序能够进行互操作。
• API开发：RESTful架构提供了一种构建API（Application Programming Interface）的方式。通过定义清晰的资源路径（URL）和使用HTTP方法来表示操作，开发人员可以设计出易于理解和使用的API接口，使得客户端能够方便地与服务端进行交互。
• 移动应用程序：RESTful是移动应用程序与服务端进行数据交换的一种常见方式。移动应用可以通过RESTful API与服务端进行通信，获取数据、提交表单、上传文件等操作，以实现与服务端的数据交互。
• 微服务架构：RESTful API在微服务架构中扮演了重要角色。不同的微服务可以通过RESTful接口进行通信和协作，每个微服务提供特定的功能，并通过HTTP请求和响应进行交互，从而实现系统的模块化和解耦。
• 资源管理系统：RESTful架构适用于构建资源管理系统，例如博客系统、电子商务平台等。每个资源（例如博客文章、商品）都可以通过唯一的URL进行访问和操作，使用HTTP方法来进行数据的增删改查操作，实现了对资源的统一管理。

总之，RESTful适用于任何需要通过网络进行通信和交互的场景，尤其适合构建分布式系统、跨平台应用和API服务。它的简单性、可扩展性和与HTTP协议的兼容性使得它成为一种广泛应用的架构风格。

示例

(1) 创建 Java API

(2) 访问API

使用工具（如 cURL、Postman 或浏览器插件）发送 HTTP 请求来测试 RESTful API，通过向 http://localhost:8080/users/{id} 发送 GET 请求来获取用户信息。

这种方式是在日常开发中最常见的一种，比如：springboot，springcloud，springMVC工程，都是基于该方式。

三、GraphQL 

定义

GraphQL 不仅是一种架构风格，同时也是一种用于构建和查询 API的查询语言，由Facebook开发并在2015年开源发布，旨在解决传统 RESTful API中的一些限制和挑战。其核心思想是客户端可以向服务器发送一个描述所需数据结构的查询，服务器将返回与查询对应的数据。这意味着客户端可以精确地指定需要的数据，并避免了在传统 RESTful API 中可能出现的过度获取或不足获取的问题。

原理

GraphQL的原理如下：

• 类型系统（Type System）：GraphQL使用类型系统来描述API的数据模型。开发人员定义数据模型中的对象类型、字段和关系，并指定每个字段的类型。这样客户端就可以准确地请求所需的数据，并且服务器可以校验和执行这些请求。
• 查询语言（Query Language）：GraphQL定义了一种灵活且表达力强的查询语言，客户端可以使用该语言来描述对API的数据需求。客户端可以指定所需的字段、关联关系和数据变换操作，以精确地获取需要的数据，避免过度获取或缺少数据的问题。
• 单一入口（Single Endpoint）：与传统RESTful API不同，GraphQL只需要一个入口点（通常是/graphql端点），客户端发送所有的请求都到这个端点。这样简化了API的维护和管理，并减少了网络请求的数量。
• 解析和执行（Parsing and Execution）：当客户端发送GraphQL查询到服务器时，服务器首先会解析查询字符串，确定所需的字段和关系。然后，服务器会执行查询，获取相应的数据并构建响应。这个过程涉及到查询的验证、字段的解析和执行以及数据的组装。
• 强大的关联查询（Powerful Relationship Queries）：GraphQL具有强大的关联查询功能，允许客户端在一个请求中获取多个关联对象的数据。客户端可以通过指定关联字段来请求相关联的数据，而无需进行多次往返请求。
• 可选参数和别名（Optional Parameters and Aliases）：GraphQL允许客户端在查询中使用可选参数，以指定条件或筛选结果。另外，别名机制允许客户端给字段起别名，以便在响应中区分相同类型的字段。
• 实时订阅（Real-time Subscriptions）：GraphQL支持实时订阅功能，允许客户端通过WebSocket等持久连接方式接收实时数据更新。这使得构建实时应用程序（如聊天、通知等）变得更加简单和高效。

GraphQL的设计目标是提供一种灵活、高效和可扩展的方式来查询和获取数据，同时减少网络请求的数量和数据的过度获取。它的语法和类型系统提供了强大的工具，使得开发人员能够更好地理解和操作API，而不仅仅是传输数据。

使用场景

GraphQL 的一些使用场景：

• 客户端驱动的数据获取：GraphQL 使客户端能够精确地指定需要获取的数据，而不是由服务端返回固定的数据结构。这种灵活性使得客户端可以通过单个请求获取多个资源的数据，减少了网络传输和数据处理的开销。
• 移动应用程序开发：对于移动应用程序，网络带宽和设备资源都是有限的。GraphQL 的能力将数据请求和响应精确匹配，可以大大减少数据传输量，提高应用程序的性能和响应速度。
• 前端开发和单页应用程序（SPA）：GraphQL 提供了一种在前端开发中自定义数据获取和管理的方式。前端开发人员可以根据需要精确地查询数据，并根据业务逻辑进行组合和转换。这种前端驱动的数据获取方式能够提高开发效率并优化用户体验。
• 多平台和多设备的数据交互：GraphQL 的灵活性使得它适用于不同平台和设备之间的数据交互，如 Web、移动应用、IoT 设备等。GraphQL 查询语言的可扩展性使得服务端可以根据客户端的需求动态调整返回的数据结构，满足不同设备和平台的需求。
• 微服务架构：GraphQL 可以作为微服务架构中的通信协议，提供服务间的数据交互和查询能力。每个微服务可以通过定义自己的 GraphQL 接口来提供特定的功能和数据，客户端可以根据需要组合和查询不同的服务。
• 实时数据和订阅功能：GraphQL 支持实时数据的订阅和推送，使得客户端可以订阅特定的数据更新或事件通知。这对于实时聊天、实时通知和实时协作等场景非常有用。

总之，GraphQL 适用于各种需要灵活、高效和可扩展数据查询的场景。它可以提高前端开发效率，减少网络传输量，适应多平台和多设备的需求，并支持实时数据交互和订阅功能。

示例

(1) 定义 GraphQL Schema

(2) 创建 GraphQL Servlet

(3) 配置启动类

(4) 发送 GraphQL 查询

使用 GraphQL 客户端（如 Altair、GraphiQL 或 Postman）发送 GraphQL 查询。根据上述示例中的映射路径 /graphql，可以通过向 http://localhost:8080/graphql 发送 POST 请求来执行 GraphQL 查询。

四、gRPC 

定义

gRPC，Google Remote Procedure Call，中文翻译为：Google 远程过程调用。它是一种高性能、跨平台的远程过程调用框架，由 Google 开发并开源。gRPC 基于 Protocol Buffers（protobuf）序列化协议和 HTTP/2 传输协议，用在分布式系统中的不同服务之间进行高效的通信。

原理

gRPC的原理如下：

• 服务定义（Service Definition）：gRPC使用Protocol Buffers（protobuf）来定义服务接口和消息格式。开发人员使用protobuf语言定义文件来描述服务的方法、输入参数和输出结果。这些定义文件可以根据需要生成不同编程语言的代码。
• 代码生成（Code Generation）：基于服务定义文件，gRPC提供代码生成工具，根据所选的目标语言生成客户端和服务端的代码。生成的代码提供了一组API，使得客户端和服务端可以进行通信和调用。
• 传输协议（Transport Protocol）：gRPC使用HTTP/2协议作为传输协议。HTTP/2相比于传统的HTTP/1.1有更好的性能和效率，支持多路复用、流和头部压缩等特性，提供了更快的数据传输和更低的延迟。
• 序列化（Serialization）：gRPC使用Protocol Buffers作为默认的序列化机制。Protocol Buffers是一种高效、可扩展的二进制数据序列化格式，可以将结构化数据序列化为紧凑的二进制格式，并进行跨语言的数据传输。
• 远程过程调用（Remote Procedure Call）：gRPC通过远程过程调用模式进行通信。客户端调用本地的Stub（客户端代理），将请求的参数封装为消息并发送给服务端。服务端接收到请求后解析消息，执行相应的逻辑，并将结果封装为消息返回给客户端。
• 流式传输（Streaming）：gRPC支持流式传输，允许客户端和服务端通过流式的方式发送和接收数据。它提供了两种类型的流式传输：单向流式和双向流式。单向流式允许客户端或服务端在一次请求或响应中发送多个消息，而双向流式允许双方同时发送和接收多个消息。
• 安全性（Security）：gRPC提供了安全性支持，可以通过TLS/SSL来保护通信的安全性。客户端和服务端可以进行身份验证和加密通信，以确保数据的保密性和完整性。

gRPC的设计目标是提供一种高性能、高效和可扩展的远程过程调用解决方案。它的使用HTTP/2和Protocol Buffers等技术，提供了快速、灵活和跨平台的通信机制，适用于构建分布式系统和微服务架构。

使用场景

gRPC具有以下几个适用场景：

• 微服务架构：gRPC在微服务架构中得到广泛应用。它提供了高效的跨服务通信机制，允许将一个大型应用程序拆分成多个独立的、可独立部署和扩展的服务。通过使用gRPC，微服务之间可以进行快速、可靠的远程过程调用，以实现分布式系统的协作。
• 客户端-服务器通信：gRPC适用于客户端和服务器之间的通信。客户端可以使用生成的gRPC客户端库来调用服务器上的远程过程。这种通信模式特别适用于需要高效、可靠和低延迟的网络通信的应用场景。
• 多语言通信：由于gRPC使用Protocol Buffers作为接口定义语言，它提供了跨多种编程语言的通信能力。这使得不同语言编写的应用程序可以通过gRPC进行通信，实现语言无关的交互。
• 实时数据传输：gRPC支持双向流式传输，这对于实时数据传输场景非常有用。它允许服务器和客户端之间建立长连接，并通过流式传输进行双向通信。这在需要实时数据传输的应用程序中非常有用，如实时聊天应用、实时数据分析等。
• 高性能要求：gRPC以其高性能而闻名。它使用基于HTTP/2的传输协议，并使用二进制数据格式，以提供更高的传输效率和更低的开销。这使得gRPC非常适合需要高性能通信的场景，如大规模数据处理、高吞吐量的系统等。

总之，gRPC适用于需要高性能、跨语言、实时通信和微服务架构的场景。它在云原生应用、分布式系统和微服务架构中得到广泛应用，并且被许多大型互联网公司所采用。

示例

(1) 定义 gRPC 服务和消息，创建xxx.proto 的 protobuf 文件，用于定义服务和消息

(2) 将 xxx.proto 生成 Java 代码，指令执行后，会生成一个对应的Java文件

(3) 创建服务端（包括实现和启动类）

(4) 创建客户端

(5 分别运行 GrpcServer 和 GrpcClient 类，启动 gRPC 服务端和客户端。服务端会监听端口 50051，客户端会向服务端发送请求并接收响应。

五、WebSocket 

定义

WebSocket 是一种在 Web 应用程序中实现双向通信的协议。相对于传统的 HTTP 请求-响应模型，WebSocket 允许服务器主动向客户端推送消息，而不需要客户端先发送请求。

原理

(1) 握手（Handshake）阶段：

• 客户端通过发送 HTTP 请求（通常是 GET 请求）向服务器请求建立 WebSocket 连接。
• 请求头中包含特殊的 Upgrade 字段，表明希望升级到 WebSocket 协议。
• 服务器在收到请求后，验证请求头，并返回特殊的响应，表示允许建立 WebSocket 连接。
• 握手成功后，客户端和服务器之间的连接从 HTTP 协议升级为 WebSocket 协议。

(2) 数据传输阶段：

• 在握手成功后，客户端和服务器之间建立了双向的持久连接。
• 客户端和服务器可以通过该连接进行实时的双向通信。
• 任一方都可以随时发送消息到对方，而不需要事先发送请求。

(3) 关闭连接：

• 任一方可以通过发送特定的消息来关闭 WebSocket 连接。
• 关闭消息会由对方接收，并响应关闭消息，最终双方的连接被关闭。

WebSocket 协议与传统的 HTTP 协议相比，有以下主要区别和特点：

• 双向通信：WebSocket 允许服务器主动向客户端发送消息，实现了真正的双向通信，而不需要客户端发起请求。
• 持久连接：WebSocket 的连接是持久的，客户端和服务器之间的连接保持打开状态，可以在长时间内保持通信。
• 较少的网络开销：与传统的 HTTP 请求-响应模型相比，WebSocket 在建立连接后只需要较少的网络开销，因为不需要频繁的建立和断开连接。
• 较低的延迟：由于实时双向通信，WebSocket 具有较低的延迟，使得实时性要求较高的应用程序更加可行。

WebSocket 协议在实时通信、实时数据更新、即时聊天、实时协作等场景中得到广泛应用。它为 Web 应用程序提供了一种更高效、更实时的通信方式，使得开发者可以构建更具交互性和实时性的应用。

使用场景

• 即时通讯：WebSocket非常适合用于实现即时通讯应用，如在线聊天、即时消息传递和实时通知。它允许服务器和客户端之间实时地发送消息，而不需要客户端不断地向服务器发起请求。
• 实时数据更新：对于需要实时更新数据的应用，如股票市场行情、即时游戏和协作编辑工具，WebSocket提供了实时性和低延迟的能力。服务器可以向客户端推送最新的数据，而不需要客户端定期轮询或刷新页面。
• 在线多人游戏：WebSocket为在线多人游戏提供了一种高效的通信机制。它可以实现玩家之间的实时互动、数据同步和事件通知，使得多个玩家能够在同一个游戏世界中实时地交互。
• 实时协作应用：WebSocket可用于实现实时协作工具，如在线白板、共享编辑工具和远程会议。它允许多个用户在同一个应用中实时地编辑、绘画、写作或演示，从而实现协同工作和即时反馈。
• 实时推送服务：对于需要向大量用户实时推送消息或事件的应用，如新闻、社交媒体和实时监控系统，WebSocket提供了高效的推送机制。服务器可以将实时数据或事件推送给订阅的客户端，以实现实时更新和通知。

需要注意的是，由于 WebSocket使用全双工连接，它需要较高的服务器资源和网络支持。在选择 WebSocket作为通信协议时，需要考虑服务器的扩展性和性能，并确保网络环境能够支持 WebSocket连接。

示例

(1) 创建服务端

(2) 创建客户端

(3) 运行服务器和客户端：分别运行 MyWebSocketServer 和 MyWebSocketClient 类，启动 WebSocket 服务器和客户端。服务器会监听端口 8080，客户端会连接到服务器并发送消息。

六、Webhook 

原理

Webhook是一种通过HTTP协议实现的回调机制，允许应用程序在特定事件发生时向指定的URL发送HTTP请求。它的原理如下：

• 事件发生：Webhook的触发是由特定事件的发生而触发的。这些事件可以是各种类型的，例如用户提交表单、新的数据记录、状态更新等。应用程序通常会在某个事件发生时触发相应的Webhook。
• 注册Webhook：应用程序通常会提供一种注册Webhook的机制，允许用户或开发者将特定的URL绑定到某个事件上。这个URL就是接收Webhook请求的目标地址。
• HTTP请求：当事件发生时，应用程序会构建一个HTTP请求，并将包含相关信息的有效载荷（Payload）作为请求的内容。通常，请求的方法是POST，并且可以包含其他相关的请求头和参数。
• 请求发送：应用程序通过将构建好的HTTP请求发送到注册的Webhook目标URL。这可以通过直接发送请求或使用HTTP客户端库实现。
• 接收和处理：Webhook目标URL上的服务端接收到请求后，可以根据请求中的有效载荷和其他相关信息来处理事件。处理的方式可以是存储数据、执行特定操作、触发其他动作等，具体取决于应用程序的需求。
• 响应：接收到Webhook请求的服务端可以返回适当的HTTP响应，以通知发送Webhook请求的应用程序请求的处理结果。响应可以包含状态码、消息和其他相关的数据。

Webhook的工作原理是基于事件驱动和 HTTP通信的机制。应用程序将感兴趣的事件与特定的URL进行绑定，并在事件发生时向该URL发送HTTP请求。目标URL上的服务端接收到请求后，执行相应的处理逻辑，并返回适当的响应。这种机制可以实现实时的、异步的事件通知和数据传递，常用于与第三方服务集成、实现自动化处理和实时通知等场景。

使用场景

Webhooks的使用场景：

• 实时通知和事件触发：Webhooks可以用于实时通知应用程序关于特定事件的发生。例如，社交媒体平台可以使用Webhooks来通知应用程序有关用户发布新帖子、评论或点赞的事件。这样，应用程序可以立即响应这些事件，进行相应的处理或更新。
• 数据同步和更新：Webhooks可以用于实现数据的实时同步和更新。当一个应用程序中的数据发生变化时，可以使用Webhooks通知其他相关的应用程序进行相应的更新。例如，电子商务网站可以使用Webhooks通知库存管理系统某个产品的库存数量发生变化，以便及时更新库存信息。
• 集成第三方服务：Webhooks可以用于与第三方服务进行集成。通过注册Webhooks，应用程序可以接收来自第三方服务的通知和数据更新。例如，支付网关可以使用Webhooks通知应用程序关于支付状态的更新，以便应用程序可以及时处理订单状态变化。
• 自动化流程和工作流：Webhooks可以用于触发自动化流程和工作流。当特定事件发生时，应用程序可以通过发送Webhooks来触发其他应用程序执行相应的操作。例如，当用户注册新账号时，应用程序可以通过发送Webhooks通知其他系统进行用户数据的创建和处理。
• 实时数据分析和监控：Webhooks可以用于实时数据分析和监控。当特定指标达到或超过阈值时，应用程序可以通过发送Webhooks通知数据分析系统或监控系统进行相应的处理和警报。这样可以及时发现和解决潜在的问题或异常情况。

总之，Webhooks是一种强大的工具，可以在不同应用程序之间实现实时通信、数据同步和自动化流程。通过使用Webhooks，应用程序可以更高效地响应事件和更新，并与其他系统进行集成，提供更好的用户体验和功能扩展性。

示例

示例很简单，通过编写了一个最常用的 HTTP 方式来调用指定的 webhook地址。 “YOUR_WEBHOOK_URL” 可以替换为实际 Webhook URL，而 Webhook URL对应的服务器可以是任何语言开发的。

在日常开发中，webhook使用最多的场景是三方服务对接，比如：三方支付，我们会在请求三方支付的参数中设置一个用户业务服务器回调地址，这样三方服务处理完数据后，可以把结果通过请求回调地址的方式进行返回，这样就可以减少业务服务器同步调用超时的问题，将同步改异步。

再比如 github的webhook功能，可当github server收到push事件时，可以webhook对应的事件，如下图：

七、总结 

本文分析了最流行的 6种 API架构风格，分别从定义到原理，从使用场景再到实例分析，每种风格都有其优缺点和合适的使用场景，或许有些架构风格是你工作中一直在使用，比如：RESTful，或许有些架构风格你不曾听过，比如：SOAP。

存在即合理，了解这些 API架构风格，一方面可以帮助我们了解 API发展的一个历史过程，一方面可以帮助我们在具体的场景选择更合适的架构风格，更重要的是，它可以更好的拓宽我们的技术视野，指不定哪一天工作中就需要使用到这种风格。

另外，比较建议的一点：当我们在遇到一个知识点时，最好是能了解这一类，这样就能做到点到面的升华，真正实现触类旁通，举一反三。