Web API 简史

2025-06-07

Web API 简史

在 1990 年代末和 2000 年代初，通过 HTTP 协议的分布式 API 的主要用途是以相对简单的远程过程调用 (RPC) 方式交换可扩展标记语言 (XML) 格式的文档。

如果您生活或工作在受影响的地区，基于 XML 的 RPC API 的一个缺点是它们关于适用专利的状态不明确（参见US7028312）。

XML-RPC 等协议演变成了简单对象访问协议 (SOAP)，从而催生了广为人知的 Web 服务。这些服务主要应用于机器与机器之间的交互，虽然也使用了万维网 (WWW) 技术，但在 Web 服务器和 Web 客户端（浏览器）之间使用并不频繁。

通过 HTTP 进行 SOAP 调用需要向 HTTP 端点发送GET或请求，并将 指定为 HTTP 标头或 URL 查询参数。尽管 SOAP 也支持不太常见的传输方式，例如电子邮件。XML 命名空间用于区分 SOAP 信封元素与 Web 服务定义的消息正文元素，但这无疑无助于提高 SOAP 消息的可读性。POSTSOAPAction

SOAP 请求示例，取自https://www.w3.org/2001/03/14-annotated-WSDL-examples：

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
      <manufacturer>K2</manufacturer>
      <model>Fatbob</model>
    </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Enter fullscreen mode Exit fullscreen mode

来自同一来源的 SOAP 响应示例：

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
      <endorsingBoarder>Chris Englesmann</endorsingBoarder>
    </m:GetEndorsingBoarderResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Enter fullscreen mode Exit fullscreen mode

由于 SOAP over HTTP 仅限于GET和POSTHTTP 方法，因此无法充分利用更广泛的 HTTP 方法（例如、 和PUT）DELETE以及与之相关的所有 HTTP 状态代码。这可能会对缓存能力产生负面影响，从而影响性能。HEADOPTIONS

AJAX

2005年2月，杰西·詹姆斯·加勒特（Jesse James Garrett）发表了一篇题为《Ajax：一种新的Web应用方法》的文章，详细介绍了谷歌开发的一种相对轻量级的方法，Web客户端可以异步（即在后台）从服务器加载内容。AJAX（异步JavaScript和XML）的全称是“异步JavaScript和XML”，它很快成为一种使网站动态化的流行方法，并由此催生了“Web 2.0”的概念。

尽管开发人员最初关注的是加载 HTML 和 XHTML 文档片段，但他们很快就开始使用 AJAX 与 Web 服务器交换数据，并且由于性能和跨浏览器兼容性等多种因素，数据格式逐渐从 XML 转向 JavaScript 对象表示法 (JSON)。然而，JSON 这一缩写却沿用至今。

曾经很常见的是，将来自多个“Web 2.0”来源的内容或数据进行整合的网站被称为“混搭”。虽然这个术语已经基本不再使用，但在一些组织名称中仍然可以看到它的影子，例如 Mashery（现为 Tibco 的一部分）和 Mashape（现为 Kong）。

AJAX 的简便性以及 jQuery 等 JavaScript 库的日益普及，导致服务器和浏览器之间 Web API 的使用量激增。自 2007 年以来，随着移动应用的兴起，Web API 的使用量更是进一步增长，这种与 JavaScript、XML 和浏览器本身分离的方式，有效地取代了 SOAP 等其他 Web API 技术。

REST 和 RESTful API

REST 一词，即表述性状态转移 (Representational State Transfer)，由 Roy T. Fielding 在其 2000 年发表的博士论文《架构风格与基于网络的软件架构设计》中提出。它旨在描述像万维网 (World Wide Web) 这样的网络以及 Web 应用程序等软件应该如何工作。它摒弃了 RPC 风格的 API 方式，提倡使用我们熟悉的万维网特性，例如：

  • 有意义的资源标识符，例如 URI
  • 传递资源表示，而不是消息或函数调用
  • 使用标准媒体类型和 HTTP 状态代码
  • 在适当的情况下明确支持缓存

传输超媒体文档（数据 - 包括文本 - 包含链接，就像超文本简单地指包含链接的文本一样）。

REST 被描述为一种架构风格，其宗旨和建议也应如此理解。REST 有很多值得学习的地方，而且在面临复杂的设计决策时，它往往是一个很好的试金石。REST 并非“新的 SOAP”，它们处理截然不同风格的 API，并且以一种根本不同的方式实现。REST 风格应用于 HTTP 时，也能充分利用这一底层协议，因此如果实现得当，性能会非常出色，尽管这并非其最初的重点。HTTP/2 的改进只会进一步提升这种性能。然而，REST 并非必须遵循的标准，也不应被视为唯一正确的道路，如同福音一样被奉为圭臬。知道何时打破“规则”与知道何时遵守“规则”同样重要，重要的是不要将严格遵守 REST 本身视为目标，尤其是在它与您或您的 API 使用者的业务需求相冲突的情况下。

REST 确实具有特定的约束，它应用于 Web 设计以定义其架构风格，就像使用帕拉第奥式或新古典主义等建筑风格来划分和描述建筑结构的范围一样。如果 API 没有展现所有强制性的 REST 约束，就不能真正称为 RESTful API。这导致了 REST-like 甚至 RESTish 等术语的出现，用于描述显示 REST 风格某些方面的 API，或者与 REST 有更多共同点而不是类 RPC API。REST 本身早于 Web API 的兴起，将 Web/Web 应用程序的 REST 风格映射到我们现在所知和描述的 API 可能会有一些困难。例如，美国白宫同时具有帕拉第奥式和新古典主义建筑的元素，但这并不意味着它就不是一座宏伟的建筑，也不会使其更容易倒塌。

“与大多数现实世界的系统一样，部署的 Web 架构的组件并非都遵守其架构设计中存在的所有约束。”

Fielding 的论文，第 6.2.5 节

通常，Web API 被称为 RESTful API，这意味着它们符合REST 架构风格所施加的大多数或全部约束。

GraphQL

2015年1月，Facebook宣布其内部客户端API将基于一项名为GraphQL的新技术构建（尽管该技术自2011年以来就以各种形式进行开发）。这是一个API框架，它既借鉴了RPC模型，也借鉴了REST及其对Web协议的使用，但同时也有自己的独特方向。

GraphQL 基于类型模式，其中数据类型及其之间的关系以接口描述语言（IDL，也称为模式描述语言或 SDL）建模，并且客户端可以使用所谓的自省查询动态查询这些信息。

GraphQL 不像 RPC 那样拥有固定的函数，也不像 REST 那样通过 URL 访问固定的资源表示，而是一种概念上类似于结构化查询语言 (SQL) 的查询语言，它允许客户端只请求执行任务所需的数据，有时还可以避免多次 API 调用来获取所有所需数据。GraphQL 还可以批量处理和组合查询。GraphQL 将查询分为仅读取数据的查询和可以修改数据的查询（称为“修改”）。

下面是一个 GraphQL 查询的示例，它使用与 JSON 类似的语法：

{ allPeople { people { name, homeworld { name }}}}
Enter fullscreen mode Exit fullscreen mode

以及来自http://graphql.org/swapi-graphql的 JSON 格式的响应摘录

{
  "data": {
    "allPeople": {
      "people": [
        {
          "name": "Luke Skywalker",
          "homeworld": {
            "name": "Tatooine"
          }
        },
        {
          "name": "C-3PO",
          "homeworld": {
            "name": "Tatooine"
          }
        },
        {
          "name": "R2-D2",
          "homeworld": {
            "name": "Naboo"
          }
        }
      ]
    }
}
Enter fullscreen mode Exit fullscreen mode

这种方法存在一些潜在的性能缺陷，因为在 HTTP 级别缓存 GraphQL 查询很困难，而且客户端可能会发出以前从未见过或未经充分测试的查询。

还有一种观点认为，GraphQL 的类型系统鼓励底层数据模型（例如 SQL 数据库模式）和呈现给客户端的数据模型之间建立更紧密的耦合（尽管情况并非总是如此）。

Facebook GraphQL 堆栈附带一个交互式控制台，称为 GraphiQL（发音为“graphical”）。其他组织也提供了 GraphQL 的实现（例如开源 Apollo 框架），并且 GitHub、Shopify 和 Yelp 等组织也公开使用了 GraphQL。

gRPC

近年来，RPC 风格的 API 以 Google 的 gRPC 形式重新流行起来（“g”代表 gRPC，是递归缩写，而不是 Google）。

从 Google 系统交换的数据量就可以看出，gRPC 注重性能，并且强制使用 HTTP/2。消息由协议缓冲区 (protobuf) 接口描述语言定义，该语言既支持文本/人类可读的序列化，也支持二进制序列化。用于生成数据并将其序列化为协议缓冲区格式的代码通常使用编译器从 protobuf IDL 生成protoc，从而实现紧凑且高性能的表示形式，尽管这种表示形式不像 HTTP/1.x 等文本传输协议那样易于检查。

gnostic是 Google 的一个开源项目，旨在允许使用 OpenAPI 规范来定义使用 protobuf 格式的 API。

感谢 Marco Palladino 捕捉到本文中的一点想法。

文章来源：https://dev.to/mikeralphson/a-brief-history-of-web-apis-47k4
Devto 翻译
PREV
从 Tailwind 迁移到 Vanilla-er CSS
NEXT
前端开发人员路线图（重温）