Web API的简史介绍

在20世纪90年代末和2000年代早期，分布式API在HTTP协议上的主要用途是以相对简单的远程过程调用（RPC）方式交换可扩展标记语言（XML）格式的文档。
诸如XML-RPC之类的协议演变为简单对象访问协议（SOAP），从而产生了广为人知的Web服务方法。这些主要是机器到机器之间的交互，尽管它们使用万维网技术，但它们在Web服务器和Web客户端（浏览器）之间很少使用。
HTTP上的SOAP调用涉及对HTTP端点的请求GET或POST请求，指定SOAPAction为HTTP标头或URL查询参数。虽然SOAP也可以支持不太常见的传输，例如电子邮件。XML名称空间用于消除SOAP信封元素与Web服务定义的消息体元素的歧义，但这可能无助于使人们更容易阅读SOAP消息。
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:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
      <manufacturer>K2</manufacturer>
      <model>Fatbob</model>
    </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

来自同一来源的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>

因为HTTP上的SOAP被限制到GET与POSTHTTP方法，它未能得到更广泛的可用的HTTP方法的益处（如PUT，DELETE，HEAD和OPTIONS）和全范围的与其相关联的HTTP状态代码。这会对可缓存性和性能产生负面影响。

AJAX
2005年2月，Jesse James Garrett发表了一篇名为Ajax：Web应用程序的新方法的文章，其中详述了Google开发的一种相对轻量级的方法，其中Web客户端可以异步地（即在后台）从服务器加载内容。代表异步JavaScript和XML的AJAX很快成为使网站变得动态的流行方法，从而产生了“Web 2.0”概念。
虽然最初涉及加载HTML和XHTML文档片段，但开发人员很快就开始使用AJAX与Web服务器交换数据，并且几个因素（例如性能和跨浏览器兼容性）导致逐渐从XML转换为JavaScript Object Notation（JSON））作为数据格式的选择。
一个将来自多个“Web 2.0”源的内容或数据组合在一起的网站称为“混搭Mash-up”。虽然这个术语已大部分不再使用，但仍然可以在组织名称中看到该术语的残余，例如Mashable（现在是Tibco的一部分）和Mashape。
AJAX的简单性和jQuery等JavaScript库的日益普及导致服务器和浏览器之间使用Web API的爆炸式增长。随着自2007年以来移动应用程序的兴起，Web API的使用量进一步增长，这种方法现在与JavaScript，XML和浏览器本身脱钩，有效地取代了其他Web API技术，如SOAP。

REST和RESTful API
REST--代表状态转移 -，这个词是由Roy T. Fielding在2000年发表的博士论文中提出的; 建筑风格与基于网络的软件体系结构设计。它旨在描述像万维网这样的网络和诸如Web应用程序之类的软件应该如何工作。它拒绝采用RPC风格的API方法，并提倡使用我们熟悉的万维网功能，例如：

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

REST被描述为一种架构风格，这就是它应该如何看待它的原则和建议。从REST中可以学到很多东西，当面对复杂的设计决策时，它往往是一个很好的回归。REST不是“新的SOAP”，它们解决了完全不同的API风格，并以一种根本不同的方式实现。当应用于HTTP时，REST样式也充分利用了这个底层协议，因此在实现良好时可以非常高效，尽管这不是它最初的重点。HTTP / 2改进带来的好处只会进一步提高性能。但是，REST不是您必须遵守的标准，也不应被视为一条真正的道路，被视为福音。知道何时打破“规则”。
REST确实具有特定的约束，它适用于Web的设计以定义其架构风格，就像Palladian或新古典主义等架构风格用于划分和描述建筑结构的范围一样。如果API没有表现出所有强制REST约束，则无法将其真正称为RESTful API。这导致了像REST这样的术语，甚至是RESTish这样的术语，用于描述显示REST样式的某些方面的API，或者与REST有更多共同点而不是类似RPC的API。REST本身早于Web API的兴起，并且在将Web / Web应用程序的REST样式映射到API时可能会遇到一些困难。
通常，Web-API被称为RESTful API，这意味着那些符合REST架构风格强加的大部分或全部约束的API 。

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 }}}}

以及JSON中的响应：

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

这种方法存在一些潜在的性能缺点，因为在HTTP级别缓存GraphQL查询很困难，并且客户端可能会发出以前从未见过或经过充分测试的查询。
还有一种观点认为，GraphQL的类型系统鼓励底层数据模型（例如SQL数据库模式）与呈现给客户端的数据模型之间更紧密的耦合（尽管情况并非总是这样）。
Facebook GraphQL堆栈提供了一个名为GraphiQL（发音为'graphical'）的交互式控制台。其他组织提供GraphQL的实现（例如开源Apollo框架），并且GraphQL由GitHub，Shopify和Yelp等组织公开使用。

GRPC
近年来，API的RPC风格以谷歌gRPC的形式出现了一些复苏（'g'代表gRPC，以递归缩写的形式出现，而不是谷歌）。
gRPC专注于性能，你可以想象谷歌系统交换的数据量，并强制要求使用HTTP / 2。消息由Protocol Buffers（protobuf）接口描述语言定义，该语言具有文本/人类可读和二进制序列化。生成协议缓冲区格式并将数据序列化为协议缓冲区格式的代码通常使用protoc编译器从protobuf IDL生成，从而形成紧凑且高性能的表示，尽管在文本传输协议（如HTTP /）的情况下不能轻易检查1.x的