困惑于什么是基于REST的API

Question

我将尝试解释REST API是什么。据我所知，它只是一个编写API函数的约定。所有函数应该是GET/POST/DELETE/PUT形式的吗？例如，在REST API中，一个函数可以是：

public string getLastName(User x)
{
    return x.lastName;
}

我主要困惑的是JSON/XML在其中扮演什么角色？

- SKLAK

---

“RESTful”服务最适合进行CRUD操作和通过单一接口访问资源。它是“SOAP”的更简化版本。“SOAP”最擅长暴露操作和应用程序逻辑。 - Brandon

REST不是CRUD，试图将REST与CRUD混淆在一起通常会导致设计不佳。REST绝对不是SOAP的更简化版本。REST可能是定义SOAP的所有内容的完全相反。 - Pedro Werneck

Answer 1

它不仅是一个惯例。 REST API 的概念是您使用 HTTP 动词访问它，并且这些动词已映射到执行所述操作的功能。

例如：

GET 将返回数据给调用者/发送者

DELETE 将删除记录

还有更多内容，但很多都基于依赖于 HTTP 提供一定程度的一致性。例如，在 RESTful 服务中，您可以使用“接受”HTTP 标头通过提供 application / json 或 application/xml 值来请求 JSON 响应或 XML 响应。这只是一个简单的例子，实现者可以决定他们的 API 如何工作，但它突显了利用 HTTP 的重要性。

为什么选择 JSON/XML？

同样，在网上广泛传输和表示数据的标准方式，JSON 和 XML 被用于这个目的。由于大多数请求来自 JavaScript，而 JS 可以轻松地与 JSON 交互而无需进行处理 XML 需要的解析，因此 JSON（JavaScript 对象表示法）在执行数据传输（特别是在 GET 请求上）时非常常见。另一方面，XML 提供了自己的优势，如使用模式和命名空间的能力。您可能已经知道每种方法的好处/缺点，但这是一个单独的讨论。主要观点是 JSON/XML 是通信 REST API 数据的主要方式，因为它们都是网络的事实标准。

有很多好的资源可以获得更多信息，本 MSDN 文章可能有所帮助：http://msdn.microsoft.com/en-us/library/dd203052.aspx

- BradleyDotNET

---

@pep 的观点非常好。如果你想在编辑中添加它们（请随意给自己归属！），我很乐意接受。 - BradleyDotNET

@pep，我已经将您的编辑内容整合进去了。在审核队列之前我没有处理它（这就是为什么最初被拒绝的原因）。再次感谢您的贡献！ - BradleyDotNET

REST不依赖于任何通信协议，因此认为REST背后的概念与HTTP动词有关是没有意义的。这个答案反映了许多关于REST在网络上广泛存在的误解。 - Pedro Werneck

您的答案声称基于REST背后的概念，但是您说是否符合原始理论并不重要？抱歉，这不太有意义。您无法谈论REST背后的概念而不涉及原始理论。您的答案反映了REST的唯一实际现实，即它如何成为指代任何非SOAP的HTTP API的流行词。 - Pedro Werneck

嗯...在REST社区中，有些人认为这是术语战争中的又一场失败之战，我们应该开始使用Hypermedia API来指代真正的RESTful API。我更喜欢采用相反的方法，为非REST API使用一个新名称。我通常称实现REST约束条件的API为Street-REST，这是最常见的情况，而对于不符合RESTful标准但能够明智地决定遵循哪些约束条件和放弃哪些约束条件的API，我则称之为Informed-REST。 - Pedro Werneck

Answer 2

REST存在很多困惑和误解。不幸的是，我们更常见到的是那些做的与REST相反的应用程序自称为RESTful，而不是真正的REST应用程序。

“从我所了解的来看，它只是API中函数的约定吗？”

不，REST不仅仅是API内部函数的约定，也不像其他答案中所说的直接与SOAP或HTTP相关。REST是一种软件架构风格，受到Web本身成功设计决策的启发。简单来说，REST API应该像网站一样工作。

当您进入一个网站时，您会进入一个主页，了解这个网站的内容，并且HTML文档将有超链接指向您需要的资源。唯一的外带信息是资源本身的媒体类型，而不是如何找到它们。例如，当您进入StackOverflow时，您知道问题和答案是什么，并寻找指向它们的链接。您的浏览器如何呈现这些链接，您如何选择并跟随它们与其他网站（如电子邮件或新闻网站）并没有区别。使其不同的是您要获取的资源的媒体类型。

这就是REST API应该工作的方式。客户端不应依赖除详细说明资源功能以外的任何外带信息。他们应连接到返回链接的主页，以执行所需的操作。如果API没有这样做，则它不是REST。简而言之。

我喜欢称这些API为“街头REST”，因为人们经常通过复制其他自称为REST的API中看到的内容以及其他人谈论REST的方式来实现它们。

“所有函数都应该是GET / POST / DELETE / PUT形式吗？”

这是一个常见的困惑，您会看到很多这样的情况，包括将其与CRUD操作混淆，或者REST不允许任何其他动词等。那是胡说八道。

REST独立于任何特定的协议，因此说函数应遵循HTTP方法是没有意义的。REST将您的应用程序约束为统一接口，这意味着无论使用什么协议，您都必须尽可能地遵循标准化行为。如果您正在使用HTTP实现REST应用程序，则这意味着您的API必须遵循客户端-服务器交互的HTTP方法，这意味着您不能像某些使用HTTP的应用程序一样发明其他HTTP方法。如果更改通信协议，则客户端需要在进入API之前了解该信息，这是更多的外带信息。

如何在代码中实现这一点与REST无关。REST不是开发模式或哲学，而是一种架构风格。

“我主要是困惑JSON / XML在其中扮演的角色？”

JSON / XML是REST API中传输数据的格式。客户端向服务器发出请求后，服务器将响应以JSON / XML格式返回。这些格式使得数据易于解析和处理，并且与REST的无状态性质相匹配。

这里也存在很多混淆。在REST应用中，您应该定义具有描述所需所有行为的状态的抽象实体。 API将用作客户端和服务器之间传输这些实体的媒体类型表示的通道。 REST代表表述性状态转移。客户端请求的URI是该资源的标识符，该请求的元数据将告诉服务器客户端准备接受哪些媒体类型。 JSON / XML根本不直接参与REST。它们只是一种表示媒体类型，对于计算机来说比如text / html等格式更容易解析和获取信息，旨在由浏览器呈现供人类可视化。

例如，以StackOverflow本身为例。抽象意义上的问题是什么？这是一个请求信息的要求。如何正式定义该抽象资源？有作者，正在提出的问题的实际文本，顶部和底部，评论和可能的答案等，所有这些都是具有自己定义的抽象资源。实际数据存储在某个数据库中，当您请求主页时，它会返回带有标识这些问题的URI的链接。以此问题为例，它具有URIhttp：//stackoverflow.com/questions/24092517。当我想在我的浏览器上渲染漂亮的文档中阅读该问题时，我将请求该URI，但是通过 Accept 标头告诉服务器我想要一个 text / html 表示，并且我的浏览器知道如何将HTML呈现为漂亮的页面。另一方面，当我想要请求该问题以将其存储回数据库时，我不需要渲染漂亮的文档页面所需的所有可爱内容，因此我要求更容易解析并且不包含大量不必要信息的格式，例如JSON或XML。

大多数构建街道REST API的人都了解这一点，但他们错过了最有趣的部分，即您不限于已经存在的媒体类型。您可以创建仅存在于API或公司应用程序生态系统中的私有媒体类型。因此，例如，而不是将所有JSON文档的媒体类型称为 application / json ，无论其中的内容如何，我们可以拥有反映特定资源类型的自定义媒体类型。因此，我们可以在JSON格式中表示StackOverflow问题的 application / vnd.stackoverflow.question.v1 + json 。一旦做到这一点，您就不必浪费时间记录通信协议已标准化的操作，而应专注于记录该自定义媒体类型以及如何与之交互，独立于通信协议。一旦您清楚了这一点，客户端就可以使用任何可用的协议与您的服务进行交互。

如果您理解了这三个主要点，您就能理解REST的含义。通过使用超链接作为应用程序状态引擎，您不会被绑定到实现的任何特定时间点。您的服务器可以随意发展，您可以随意更改URI，而客户端不会出现问题。通过遵循标准化协议，通用客户端更容易使用您的API，更不用说如果他们已经知道您不会破坏协议，那么开发人员更容易理解如何集成。通过将设计和文档编制工作集中在媒体类型上，而不是协议细节和URI语义上，您可以避免引入更多驱动API所需的带外信息，并且您的客户端也更具有弹性来应对变化。

- Pedro Werneck

---

一个非常好的解释。然而，我不确定这有多么有用，因为（引用自MSDN）“虽然从理论上讲REST并没有与任何特定的平台或技术绑定，但Web是唯一完全体现REST的主要平台。因此，在实际应用中，如果你要构建一个RESTful的东西，你可能会使用HTTP在Web上进行。”我们（通常）不是StackOverflow上的理论家，我们正在寻找实际的编程知识。在实践中，REST与HTTP密切相关。 - BradleyDotNET

抱歉，我之前已经听过“实际”或“务实”的论点，但它并不成立。如果你是在说这是人们在实践中所做的事情，并称其为REST，那么好吧，这是实际的，但它只是一个流行词。街头REST并不实用，也无法有效地解决REST旨在解决的问题。它解决了另一组问题。如果你想称之为REST，我不会阻止你，但当有人问到什么是基于REST的API时，我认为他应该得到正确的答案。 - Pedro Werneck

从来没有说过这不是一个答案 :) 我认为这两个信息的结合非常重要，我只希望有一种简单的方法将理论转化为实用信息，以供那些想使用REST服务（或者也许我们应该想出一个新名称）的人使用。 - BradleyDotNET

Answer 3

REST API充当中间人，在Web服务和应用程序之间传递数据包，以便应用程序可以使用Web服务中的某些资源进行操作。为了实现这一点，Json发挥了作用，它有助于通过通道进行数据传输/通信。当一个应用程序希望获取资源列表时，实际上从数据库中获取复杂的数据或查询集，然后通过序列化将其转换为简单的数据类型，再将其转换为json以遍历通道。

- Amit Verma

Answer 4

RESTful API不仅仅是编写函数的约定。

REST的缩写代表“REpresentational State Transfer”。

REST API用于调用资源，并允许软件基于标准化原则、属性和约束进行通信。REST API基于简单的请求/响应系统运作。您可以使用以下HTTP方法发送请求：

• GET
• POST
• PUT
• PATCH
• DELETE

此外，REST API还可以包括端点、标头、URL参数和请求正文。

端点（或路由）是您请求的URL。路径确定您正在请求的资源。将其视为自动接听电话的答录机，要求您按1获取服务，按2获取另一个服务，按3获取另一个服务，以此类推。

我主要困惑的是JSON/XML在其中扮演的角色？

当您向端点发送请求时，它会响应相关数据，通常格式化为JSON、XML、纯文本、图像、HTML等。

- Pratham

Answer 5

“我主要困惑于JSON/XML在这方面扮演了什么角色？” “JSON/XML被称为流数据格式。还有其他格式，但这两种因其提供低延迟而逐渐流行起来。XML可能仍比JSON稍微流行一些，但JSON更紧凑。” “另一个主要原因是它们都被几乎所有语言及其框架支持。”

- Md Nazmoon Noor

---

我很好奇你从哪里得到了“流数据格式”这个术语，我不认为它们本质上有任何“流式”的特点。我还要说，在网络上，JSON 更受欢迎。除非你计算 WCF，否则 XML 几乎只用于“本地”目的。 - BradleyDotNET

我猜它从来没有被确定下来，但有些情况被使用了。http://java.dzone.com/articles/streaming-apis-json-vs-xml-and - Md Nazmoon Noor

我认为你把流式 API（在我看来仍然是一个糟糕的名字）和数据类型弄混了。文章从未声称数据类型是流式传输的。不过这是一篇有趣的文章，谢谢你分享链接！ - BradleyDotNET