本课程的所有内容都是边做边学，但是在进行各种活动时，我会定期停下来并深入探讨一些更抽象的概念以补充更多细节。这个主题是深入概念的时刻之一。在这里，我们将探讨REST API是什么，并将其与SOAP等其他类型的API进行比较。REST API具有共同的特征，但是没有像其SOAP的前身那样的确定性协议。

目录

• 什么是API？
• 使用HTTP协议的API是“网络服务”
• SOAP API是 REST API的前身
• REST是一种风格，而不是一种标准
• REST专注于通过URL访问的资源网络本身
• 遵循RESTREST API是无状态且可缓存的
• REST API不使用WSDL文件，但是存在一些规范
• 补充阅读

什么是API？

通常，API（或应用程序编程接口）提供两个系统之间的接口。就像是一个齿轮，它允许两个系统相互交互。在这种情况下，这两个系统是通过API进行编程交互的计算机。

API通常会在用户界面下提取和推送数据。考虑像kayak. com 或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

‌API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

‌API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

‌API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

‌API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据

API通常会在用户界面下提取和推送数据。考虑像kayak.com或orbitz.com这样的机票预订网站的示例。当您搜索航班时，该网站会与许多其他航空公司服务联系，以检索与您的查询匹配的航班信息。kayak.com本身不具备所有这些信息。而是通过API收集此数据。

或考虑其他类似服务。当您看到网站上嵌入的YouTube视频时，该网站本身不会托管该视频。相反，嵌入代码包含API请求，这些请求从YouTube的托管中心获取视频。当您在网站上嵌入Twitter小部件时，该小部件的API将来自Twitter服务器的推文拉到您的网站上。

考虑消防电视的另一个例子。假设您要查看需要付费的按次计费事件。可能会出现一个弹出对话框，让您输入信用卡详细信息。付款已处理完毕，您会收到有关购买成功的确认。该应用程序内不会进行此付款处理。相反，该应用程序使用所需的信息使API调用支付服务器，所有支付处理都在云中进行。处理完成后，API将返回确认响应。

下次您在某个界面中按下按钮时，请考虑下面的情况。最有可能的是，该按钮在内部进行了布线，以致电外部服务以获取所需的信息。该调用是通过执行请求并接收响应的API进行的。

使用HTTP协议的API是“网络服务”

“ Web服务 ”是基于Web的应用程序，以其他计算机可使用的格式提供资源。Web服务包括各种类型的API，包括REST和SOAP API。Web服务本质上是客户端和服务器之间的请求和响应交互（计算机请求资源，而Web服务响应请求）。

‌使用HTTP协议作为请求和响应的传输格式的所有API均被视为“ Web服务”。使用网络服务，请求资源的客户端和提供响应的API服务器可以使用任何编程语言或平台，这没关系，因为消息请求和响应是通过通用的HTTP网络协议进行的。

‌Web协议是Web服务之美的一部分：它们与语言无关，因此可以在不同的平台和系统之间进行互操作。在记录REST API时，工程师是否使用 Java ，Ruby，Python或其他某种语言来构建API都没有关系。请求是通过HTTP发出的，响应是通过HTTP返回的。下图显示了REST API的一般模型：

如您所见，客户端与API服务器之间存在请求和响应。客户端和服务器可以使用任何语言，但是HTTP是用于传输消息的协议。这种请求和响应模式从根本上就是REST API的工作方式。

发出请求的每种编程语言都将以不同的方式提交Web请求并以其语言解析响应。这些用于发出请求和解析响应的特定于语言的功能不是REST API的一部分（尽管它们可能在随附的SDK中提供）。REST API与语言无关，可以像处理Web一样通过HTTP处理传入和传出的信息。

SOAP API是REST API的前身

在REST成为最流行的Web服务之前，SOAP（简单对象访问协议）更为普遍。为了更好地理解REST，使用SOAP可以有一些上下文。通过这种方式，您可以了解使REST与众不同的原因。

SOAP是一种标准协议，需要XML作为请求和响应的消息格式。作为标准化协议，消息格式通常通过称为WSDL（Web服务描述语言）文件的方式来定义。

WSDL文件定义了消息交换中允许的元素和属性。WSDL文件是机器可读的，并且由彼此交互以促进通信的服务器使用。

SOAP消息使用特定的XML模式和名称空间包含在包含标题和正文的“信封”中。有关SOAP请求和响应格式的示例，请参阅SOAP与REST 101：了解差异。

SOAP的主要问题是XML消息格式过于冗长和繁琐。对于文件大小和带宽至关重要的移动方案，这尤其成问题。详细的消息格式减慢了处理时间，这使SOAP交互变得昏昏欲睡。

SOAP仍用于服务器到服务器通信的企业应用程序场景（尤其是在金融机构中），但是在过去的五年中，SOAP已被REST取代，尤其是开放Web上的API。

REST是一种风格，而不是一种标准

与SOAP一样，REST（表示状态传输）使用HTTP作为消息请求和响应的传输协议。但是，与SOAP不同，REST是一种体系结构样式，而不是标准协议。这就是为什么REST API有时称为 RESTful API的原因-REST是API遵循的一种通用样式。

正如最早描述该模型的Roy Fielding博士所概述的那样，RESTful API可能不符合REST的所有正式特征。因此，这些API是“ RESTful”或“类似REST”的。（当API不能满足REST的所有特征时，一些开发人员会坚持使用“ RESTful”一词，但无论如何，大多数人都将它们称为“ REST API”。）

作为一种建筑风格，您不仅限于XML作为消息格式。REST API可以使用API​​开发人员想要使用的任何消息格式，包括XML， JSON ，Atom，RSS，CSV，HTML等。

尽管有多种消息格式选项，但大多数REST API均使用JSON（JavaScript对象表示法）作为默认消息格式。他们使用JSON是因为JSON提供了一种轻量级，简单且更灵活的消息格式，可提高通信速度。JSON的轻量级特性还允许进行移动处理，并且可以使用JavaScript在Web上轻松解析。

相反，对于XML，XSLT被更多地用于呈现或“转换”（XSLT中的“ T”）以XML语言存储的内容。XSLT使人可读（而不是处理以XML格式存储的数据）。

REST专注于通过URL访问的资源

REST的另一个独特方面是REST API着重于资源（即事物而不是动作）和访问资源的方式。资源通常是不同类型的信息。您可以通过URL（统一资源定位符）访问资源，就像在浏览器中转到URL检索信息资源一样。

URL附带有一个方法，该方法指定您如何与资源交互。常用方法包括GET（读取），POST（创建），PUT（更新）和DELETE（删除）。端点通常包含查询参数，这些查询参数指定有关要查看的资源表示形式的更多详细信息。例如，您可以（在查询参数中）指定要将显示限制为该资源的5个实例。端点示例如下所示：

端点显示了资源的完整路径。但是，在文档中，通常将此URL分为更具体的部分：

• 基本路径（或基本URL或主机）是指API的通用路径。在上面的示例中，基本路径是。
• 端点是指端点的结束路径。在上面的示例中，/ homes。
• 端点的？limit = 5＆format = json部分包含端点的查询字符串参数。

在上面的示例中，此终结点将获取“房屋”资源并将结果限制为5个房屋。它将以JSON格式返回响应。您可以有多个引用相同资源的端点。这是一种变体：

 {home id}  

上面的URL可能是一个端点，该端点检索包含特定ID的家庭资源。从服务器传输回客户端的是资源的“表示”。该资源可能具有许多不同的表示形式（显示所有房屋，符合特定条件的房屋，特定格式的房屋等），但是在这里我们希望看到具有特定ID的房屋。

我们将在后续章节中更深入地探讨端点（例如，在API参考教程中，我们将研究资源中的每个属性）。但我想在此提供简要概述。

网络本身遵循REST

通过“ HTTP协议”传输的“ GET请求”和“消息响应”术语似乎不熟悉，但这只是描述正在发生的事情的官方REST术语。因为您使用过网络，所以您已经熟悉REST API的工作原理-网络本身实质上就是RESTful风格。

如果您打开浏览器并访问，则实际上是在使用HTTP协议（https：//）向Web服务器上的可用资源提交GET请求。服务器的响应会使用HTTP将此资源上的内容发送回给您。您的浏览器只是一个使消息响应看起来漂亮的客户端。

如果打开终端提示符并键入curl ，则可以在curl中看到此响应。（这假定您已安装curl。）

由于Web本身就是RESTful样式体系结构的一个示例，因此REST API的工作方式将很可能成为您的第二天性。

REST API是无状态且可缓存的

REST API也是无状态且可缓存的。无状态意味着每次您通过端点访问资源时，API都会提供相同的响应。它不会记住您的上一个请求，并在提供新回复时将其考虑在内。换句话说，以前没有任何一种状态可以将API与每个请求都考虑在内。

响应也可以被缓存以提高性能。如果浏览器的缓存中已包含请求中要求的信息，则浏览器可以仅从缓存中返回信息，而无需再次从服务器获取资源。

REST API的缓存类似于网页的缓存。浏览器使用HTTP标头中的上次修改时间值来确定是否需要再次获取资源。如果自上次检索以来没有修改过内容，则可以使用缓存的副本。缓存可以提高响应速度。

REST API具有其他特征，您可以在此REST API教程中更深入地研究它们。这些特征之一包括响应中的链接，以允许用户翻页至其他项目。此功能称为HATEOAS，或作为应用程序状态引擎的超媒体。

‌在更高的理论层面上了解REST不是我的目标，也不是记录REST API的必要知识。但是，有许多技术书籍，课程和网站都更深入地探讨了REST API的概念，约束和体系结构，您可以根据需要咨询。例如，在lynda.com上查看David Gassner的《编程基础：Web服务》。

REST API不使用WSDL文件，但是存在一些规范

REST API的一个重要方面，尤其是在文档方面，是它们不使用WSDL文件来描述请求和响应中允许的元素和参数。尽管可能有一个WADL（Web应用程序描述语言）文件可用于描述REST API，但很少使用WADL文件，因为它们不能充分描述REST API的所有资源，参数，消息格式和其他属性。。（请记住，REST API是体系结构样式，而不是标准化协议。）

要了解如何与REST API交互，您必须阅读API的文档。阅读文档的需求使技术作者的角色对于REST API极为重要。已经开发了一些正式的规范（例如 OpenAPI 和RAML）来描述REST API。当您使用OpenAPI或RAML规范描述API时，可以读取这些规范的工具（例如Swagger UI或RAML API Console）将生成交互式文档输出。

OpenAPI规范文档可以代替SOAP更常见的WSDL文件。诸如Swagger UI之类的读取规范文档的工具通常会生成交互式文档（带有API控制台或API Explorer），并允许您尝试REST调用并直接在浏览器中查看响应。

但是不要指望Swagger UI或RAML API控制台文档输出会包含用户使用您的API所需的所有详细信息。例如，这些输出将不包括有关授权密钥的信息，有关工作流的详细信息以及端点之间的相互依赖性等。Swagger或RAML输出通常仅包含参考文档，通常仅占所需文档总数的三分之一或一半（取决于API）。

总体而言，REST API比SOAP API更加多样化和灵活，您几乎总是需要阅读文档以了解如何与REST API进行交互。在探索REST API时，您会发现它们之间存在很大差异（特别是它们的文档站点的格式和显示，我们将在Survey of API doc site中进行介绍），但是它们都具有相同的通用模式这里。任何REST API的核心都是通过Web传输的请求和响应。