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

澄清：

REST是architectural style（为了完整性而重复，在这一点上你似乎很清楚。）
万维网是一个参考应用程序，（主要）演示了这种架构风格。
HTTP 一个三个＆＃34;核心＆＃34;网络堆栈中的技术。

如果基于HTTP实现REST，我在HTTP和REST之间找不到明显的区别。

简短的回答是单靠HTTP是不够的。

Jim Webber (2011)

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

我们有申请在HTTP之前通过网络传输文件 - 文件传输协议，gopher，wais ......所有这些都对公众的影响微乎其微。相比之下，网络是灾难性的成功;这是互联网的killer app。

菲尔丁的论文 - 特别是Chapter 6: Experience and Evaluation - 除其他外，是对问题的探索＆＃34;为什么网络如此成功？＆＃34;重点关注保护网络诱导特性的建筑约束。

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

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

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

这些技术不会实现poka-yoke。也就是说，这些技术不会强迫您完全，正确或最佳地使用它们。

Ian S Robinson在2010年的演讲中提到了类似的观点The Counterintuitive Web。

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

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

您可以在HTTP上执行所有这些操作，协议标准不会限制您。

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

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

中间的一个是Rails - Jim Webber，2011。

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

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

菲尔丁的论文为我们提供了uniform interface：

的定义

REST由四个接口约束定义：资源识别;通过陈述来处理资源;自我描述性的信息;并且，超媒体作为应用程序状态的引擎。

超媒体是巨大的，但它不是HTTP - 在网络堆栈中，超媒体支持来自HTML。这是Richardson模特中的最高水平;实施Web服务时经常被误解的技术。

正如Fielding (2008)直言不讳地说，这种架构约束不是可选的：

在超文本是一种约束的概念上，需要做些什么才能使REST架构风格明确？换句话说，如果应用程序状态的引擎（以及API）不是由超文本驱动的，那么它就不能是RESTful，也不能是REST API。期。

应输入REST API，除了初始URI（书签）和标准化媒体类型集之外没有先验知识....从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动存在于收到的陈述中或由用户操纵这些陈述所暗示的。

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

专业化和创新取决于一个开放的集合。注意暗示：开放集合可能会发生变化并且无限。变更是非常真实的 - 作为参考，请参阅有关API版本控制的任何讨论。将独立开发的客户连接到一组开放的资源是完全不合理的。

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

它做了很多工作 - 在短期内更容易将可用资源传送给客户带外（即API文档），允许您使用不指定的表示超媒体控制元素（例如：application / json）。

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

给予＆＃34;长寿＆＃34;规模感 - httpd最初是在25年前实现的，HTTP的最前沿是版本 2 。 HTML更不稳定（并且更旧）;它一直到版本 5 （由于WHATWG认为HTML为living standard这一事实而有点混淆。）

有一些像Jersey JAX-RS这样的API，它基于HTTP为REST提供API实现。他们在HTTP基础知识上添加了哪些额外功能？

嗯......不是很多？

这不是一个特别慈善的答案，菲尔丁是expert members之一，所以你被邀请带着我的怀疑态度。

但这就是Marc Hadley在2008年所说的话

我认为API鼓励以资源为中心的视图，并让开发人员考虑其资源的标识符及其支持的方法。对内容协商的声明性支持很有效，默认资源生命周期鼓励无状态方法。

建议，在观看Stefan Tilkov的演讲REST: I don't think it means what you think it does (slides)时，请记住＆＃34;考虑其资源的标识符＆＃34; 。

这里的Marc Hadley关于工作的弱点

如果我必须确定一个弱点，它必须有限支持超媒体作为状态引擎 - 同时我们提供了很好的支持，从请求URI中提取信息并构建URI到资源，仍然非常需要开发人员在表示中适当地使用超媒体。

是的，生成和解析设计精美的URI具有价值。但是，设计良好的标识符不属于REST架构约束。 超媒体是。

总之，如果您希望了解HTTP和REST之间的区别，JAX-RS将无法提供帮助。

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

1 个答案: