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

Question

我知道REST原则上与HTTP无关。 HTTP是协议，REST是用于通过Web传输hypermedia的体系结构样式。 REST可以使用诸如HTTP，FTP等的任何应用程序层协议。关于REST的讨论很多，大多数都有些混乱。例如。; REST，non Rest。

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


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


如果我仔细研究HTTP / 1.1的规范RFC，就会指出HTTP是Stateless，server-client，使用URIs来寻址资源。因此，有关Roy Fielding讨论的这些约束已经存在于HTTP中。

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

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

Answer 1

说明：

REST是architectural style（为完整性起见，您似乎已经清楚了）。
万维网是一个参考应用程序，它（大多数）演示了该体系结构样式。
HTTP是Web堆栈中的三种“核心”技术之一。


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

简短的答案是仅凭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。期。
在输入REST API之前，除了初始URI（书签）和标准媒体类型集之外，应该没有其他任何知识。...从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动在接收到的表示形式中或由用户对这些表示形式的操纵所隐含。

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

专业化和创新取决于开放的环境。请注意其中的含义：开放集可能会发生变化并且是无限的。更改是很现实的事情-供参考，请参阅有关API版本控制的所有讨论。将独立开发的客户与一组开放资源耦合在一起是完全不合理的。
但是借助超文本，可以使用一组封闭的资源（书签）为客户提供表示形式，将其引导到今天的开放资源集，然后在明天进行创新时更改带书签的表示形式。
不过，这需要大量工作-短期内将可用资源带外传达给客户端更加容易（例如API文档），这使您可以使用未指定超媒体控制元素的表示形式（例如：application / json）。

REST适用于跨越多个组织的长期基于网络的应用程序。如果您认为不需要约束，请不要使用它们。

为了使“长寿”具有规模感，httpd最早是在25年前实施的，而HTTP的最先进版本是版本2。一直到版本5为止（编号因WHATWG认为HTML是living standard而感到困惑）。

有一些API，例如Jersey JAX-RS，可为基于HTTP的REST提供API实现。他们在HTTP基础上增加了哪些额外功能？

嗯...不是很多吗？
这不是一个特别慈善的答案，而菲尔丁（Fielding）是expert members之一，所以邀请您对我的怀疑表示怀疑。
但是，这是马克·哈德利（Marc Hadley）在2008年不得不说的话

我认为API鼓励以资源为中心的观点，并使开发人员考虑其资源的标识符和所支持的方法。对内容协商的声明式支持效果很好，并且默认资源生命周期鼓励采用无状态方法。

建议，当您观看Stefan Tilkov的演讲REST: I don't think it means what you think it does (slides)时，请记住“考虑其资源的标识符”。
这是马克·哈德利（Marc Hadley）关于作品的弱点

如果我必须确定一个弱点，那么它就必须有限地支持作为状态引擎的超媒体-虽然我们为从请求URI中提取信息并为资源构建URI提供了很好的支持，但开发人员仍然可以使用超媒体适当地表达。

是的，精心设计的URI的生成和解析具有价值。但是，设计良好的标识符不在REST体系结构约束之列。超媒体是。
总之，如果您想了解HTTP和REST之间的区别，JAX-RS将无济于事。