架构格调是如何演进的 API

随着软件架构的开展，支持系统之间通讯的API格调也在不时演化。SOAP、REST、GraphQL和RPC是四种盛行的API架构格调，各自提供了共同的数据替换形式，且均为满足特定需求而出现。

SOAP 是最早的 API 规范之一，于上世纪90年代末开发，关键用于支持企业环境中复杂且高度结构化的数据替换。SOAP 是协定而非格调，它定义了严厉的信息格局、安保性（经过WS-Security）和失误处置规范。SOAP 依赖 XML 格局，并能在 HTTP、SMTP 等协定上运转。SOAP 的严厉规范提供了高牢靠性和安保性，实用于金融、支付系统等须要高安保性的运行场景。

但是，SOAP 的复杂性和简短性使其在轻量级、基于 Web 的运行中不够灵敏。随着期间推移，SOAP 逐渐被更繁难、灵敏的代替打算取代，但在遗留系统和企业环境中依然被宽泛经常使用。

REST 由 Roy Fielding 于 2000 年代早期提出，是一种更灵敏的架构格调。与 SOAP 不同，REST 不是协定，而是一套指点 API 设计的准则。RESTful API 经常使用 HTTP 方法（GET、POST、PUT、DELETE）来将 CRUD 操作（创立、读取、更新、删除）映射到资源上，这些资源经过 URL 示意。

REST 提供了极大的繁复性和灵敏性，使其易于经常使用，十分适宜 Web 运行。它支持不同的数据格局（如 JSON、XML 等），其中 JSON 因其可读性和轻量特性而被宽泛驳回。REST 的有形态性和对 HTTP 的遵照使其便于裁减，但有时会造成数据的适度失掉或无余失掉，由于客户端通常会失掉到比所需更多或更少的数据。虽然存在这些限度，REST 仰仗易于成功和宽泛的 HTTP 支持成为 Web API 的实践规范。

GraphQL 由 Facebook 于 2012 年开发，旨在处置 REST 的一些局限性，它准许客户端在一次性恳求中准确地指定所需的数据。GraphQL 不像固定的资源端点，而是提供了一种灵敏的查问系统，客户端可以恳求详细的字段和相关。

GraphQL 经过防止数据的适度失掉和无余失掉提高了效率，特意实用于数据需求复杂的运行，如带宽和性能关键的移动运行和单页运行。但是，GraphQL 在主机成功、缓存和性能优化方面引入了额外的复杂性。GraphQL 实质上是有形态的，这或许会影响某些场景的可裁减性。

RPC 是最早的通讯协定之一，准许客户端像在本地一样在远程主机上口头函数（或环节）。RPC 可驳回 JSON-RPC、XML-RPC 或 Protocol Buffers（如gRPC）等格局，通罕用于繁难极速的场景。

与更倾向资源的 REST 和 GraphQL 不同，RPC 是面向举措的，将端点视为可调用函数。gRPC 是由 Google 开发的一种RPC框架，应用 HTTP/2 和 Protocol Buffers 来成功高性能、低提前的通讯，十分适宜微服务架构。但是，RPC 的紧耦合形式降落了灵敏性，使 API 版本治理愈加复杂。

API 格调依据对繁难性、性能、灵敏性和开发效率的需求而不时演进。在SOAP、REST、GraphQL 和 RPC 之间的选用取决于运行的详细需求：

在现代软件中，通常会依据运行不同局部的需求联合经常使用这些格调。每种格调都有其长处，了解它们可以协助开发者为 API 战略选用最佳工具。