使用基于 REST 的 API 可以实现哪些功能/约束不能仅使用基于 HTTP 的 API

Posted 2023-02-16

技术标签:

【中文标题】使用基于 REST 的 API 可以实现哪些功能/约束不能仅使用基于 HTTP 的 API【英文标题】：What features/constraints can be achieved with REST based API that cannot be with only HTTP based API 【发布时间】：2016-11-29 13:42:08 【问题描述】：

我知道REST 原则上与HTTP 无关。 HTTP 是一种协议，REST 是一种架构风格，用于 hypermedia 在 Web 上传输。 REST 可以使用任何应用层协议，如HTTP、FTP 等...关于REST 的讨论很多，大部分都有些混乱。例如。; REST，non Rest。

大多数情况下，REST 会对任何应用程序协议（例如 HTTP 等）施加以下约束。例如在Fielding's论文中。

客户端-服务器` 无状态可缓存分层系统按需代码统一界面

如果我仔细研究RFC，HTTP/1.1 的规范，据说HTTP 是Stateless，server-client，使用URIs 来寻址资源。所以Roy Fielding 谈到的这些约束已经存在于 HTTP 中。

有一些像Jersey JAX-RS这样的API，为REST提供基于HTTP的API实现。他们在 HTTP 基础上添加了哪些额外功能？ PUT、GET 等所有方法都在HTTP 中。

如果 REST 是基于 HTTP 实现的，那么我没有发现 HTTP 和 REST 之间的明显区别。

【问题讨论】：

REST 是一种使用 HTTP 来实现您所报告的好处的方式。 HTTP 也可以像 SOAP 一样被（错误地）用作传输协议。 HTTP 不会自动成为 REST，REST 不仅仅是 HTTP。这可以帮助你理解：***.com/a/13034235/5115768 @MaVVamaldo 我所说的所有好处都是 HTTP 本身的规范。例如，我们不能基于 HTTP 规范开发 Web 服务吗？为什么人们使用 REST 来实现那些已经存在于 HTTP 中的功能。 @lenny 我已经在我的问题中添加了这个链接，这并不能解决我的困惑。 【参考方案1】：

说明：

REST 是一个architectural style（为了完整起见，重复一遍，您似乎很清楚这一点）。万维网是一个参考应用程序，它（主要）展示了这种架构风格。 HTTP 是网络堆栈中三种“核心”技术中的一种。

如果 REST 是基于 HTTP 实现的，我没有发现 HTTP 和 REST 之间的明显区别。

简短的回答是仅 HTTP 是不够的。

Jim Webber (2011)

HTTP 是一种应用协议，其应用领域是通过网络传输文档。

在 HTTP 之前，我们有通过网络传输文档的应用程序——文件传输协议、gopher、wais...所有这些对公众的渗透率都可以忽略不计。相比之下，网络取得了灾难性的成功。它是互联网的killer app。

菲尔丁的论文——尤其是Chapter 6: Experience and Evaluation——是对“为什么网络如此成功？”这个问题的探索。重点是保护网络诱导属性的架构约束。

2008 年，Leonard Richardson 介绍了他的 maturity heuristic，用于评估 Web 服务。

[URI + HTTP + html] 构成了 Web 服务的技术栈。当人们设计 Web 服务时，他们倾向于从堆栈底部挑选一些技术。您可以通过查看他们选择零、一、二或三项技术来粗略地判断它们。

当我说你从堆栈中挑选时，我并不是说你会找到一个根本不使用 HTTP 或没有 URI 的 Web 服务。我的意思是有一类 Web 服务并没有真正获得 URI 或没有真正获得 HTTP。如果您的 REST 雷达经过微调，您会感觉到这些服务有问题，您可以谈论违反 RESTful 约束，但这是一种不流血的谈话方式。不清楚为什么有人应该关心。

这些技术没有实现poka-yoke。也就是说，这些技术不会强迫您完全、正确或发挥最佳效果。

Ian S Robinson 在 2010 年的演讲 The Counterintuitive Web 中谈到了类似的情况。

在演讲中，我描述了我们如何在（RESTful）Web 应用程序中实现丰富而有趣的业务流程，但前提是我们要考虑协议资源，而不是粗粒度的域资源。通过将网络首先视为数据网络，使用一组封闭的动词以同样古老的方式操作的一组开放的资源表示，我们的设计捕获了大多数基于 CRUD、以数据为中心的行为应用程序非常缺乏。

这张幻灯片取自那次演讲，展示了三种不同的资源设计：

你可以在 HTTP 上做所有这些，协议标准不限制你。

幻灯片顶部的设计有一个 RPC 字符：通过向单个端点发送许多不同的消息来执行业务协议。参与业务协议仅限于对话中识别此特定接口的那些组件；简而言之，开箱即用的标准 http 组件无法实现规模化。

底部的设计有一个 REST 字符：许多个端点（资源），但业务协议是通过一组受约束的消息（即统一接口）执行的，这些消息已明确指定语义。通过将协议复杂性从消息转移到资源，消息交换变得与业务协议无关——您可以使用标准组件实现扩展，因为它们可以参与表示交换，而无需任何专业化。

中间的是 Rails -- Jim Webber，2011 年。

统一界面的概念对于网络的成功至关重要；它是允许客户端（浏览器、爬虫）和中介（缓存、反向代理）独立于服务器开发的约束。

使用基于 REST 的 API 可以实现哪些功能/约束不能仅使用基于 HTTP 的 API 实现

菲尔丁的论文给了我们uniform interface的这个定义：

REST 由四个接口约束定义：资源标识；通过表示来操纵资源；自我描述的信息；并且，超媒体作为应用程序状态的引擎。

超媒体是巨大的，但它不是 HTTP——在 Web 堆栈中，超媒体支持来自 HTML。这是理查森模型中的最高水平；实现 Web 服务时最常被误解的技术。

正如Fielding (2008) 直言不讳的那样，这个架构约束*不是可选的：

需要做些什么来使 REST 架构风格清楚地认识到超文本是一种约束？换句话说，如果应用程序状态引擎（以及 API）不是由超文本驱动的，那么它就不能是 RESTful 并且不能是 REST API。期间。

除了初始 URI（书签）和一组标准化媒体类型之外，应该在没有任何先验知识的情况下输入 REST API……从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动存在于接收到的表示中或由用户对这些表示的操作所暗示的。

从根本上说，使用 REST API 就像 browsing wikipedia

专业化和创新依赖于开放集。 请注意其中的含义：开放集具有潜在的变化和无限的可能。变化是一件非常真实的事情——作为参考，请参阅关于 API 版本控制的任何讨论。将独立开发的客户端与一组开放的资源耦合起来是完全不合理的。

但是对于超文本，可以使用一组封闭的资源（书签）向客户提供将他们引导到今天的开放资源集的表示，然后在明天进行创新时更改带有书签的表示。

虽然工作量很大，但在短期内更容易将可用资源与客户端进行带外通信（即 API 文档），这允许您使用不指定超媒体控制元素的表示（例如: 应用程序/json)。