REST和HATEOAS是否是Web服务的良好架构？

如果我理解正确，那么REST被Roy Fielding正式化为Web体系结构的描述性模型。AFAIK Fielding并不认为REST很好，他只是在描述Web的实际架构。在这一点上，网络已经证明了一个巨大的成功的分布式超文本系统，因此，这种验证将REST作为主要由人类导航和使用的分布式超媒体领域的成功架构。

REST Web服务是通过将REST体系结构应用于API来创建的。但是实际上是否有任何理由认为REST是该领域的理想架构？更具体地说，是否有证据表明HATEOAS是机器对机器通信的有益设计原则？

我担心的是HATEOAS对于超媒体有意义，因为很少有众所周知的内容类型（HTML，图像，视频等），并且客户端知道如何使用它们。但是对于API来说，内容类型是非常特定的，并且如果客户端经过专门编程以使用它们，则客户端只能以有意义的方式使用它们。向客户端返回URL本身并不能使客户端能够使用指示的资源。

AFAIK Fielding并不认为REST很好，他只是在描述Web的实际架构。

我想，这让它有些不足。REST是，毕竟枚举建筑风格是菲尔丁使用作为总设计师HTTP / 1.1规范。

但是实际上是否有任何理由认为REST是该领域的理想架构？是否有证据表明HATEOAS是机器对机器通信的有益设计原则？

“这取决于”。HATEOAS是REST 统一接口约束的一部分。

通过将通用性的软件工程原理应用于组件接口，简化了整个系统架构，并提高了交互的可见性。实施与提供的服务脱钩，从而鼓励了独立的可扩展性。但是，要权衡的是，统一的接口会降低效率，因为信息是以标准化形式而不是特定于应用程序需求的形式传输的。REST接口被设计为对于大颗粒超媒体数据传输是有效的，针对Web的常见情况进行了优化，但是导致该接口对于其他形式的体系结构交互不是最佳的。

因此，让我们考虑一下这意味着什么。当我在无线路由器上遇到问题时，可以使用与用于向stackexchange提交答案的浏览器相同的浏览器进行通信。特别是，我使用的浏览器是什么，或者我的浏览器是否比路由器期望的更新晚（或更新）都没有关系。编写浏览器的工程组织完全独立于创建路由器接口的组织也没关系。

它只是工作。

当然，这不是普遍的。 菲尔丁在2008年写道：

这并不意味着我认为每个人都应该根据REST架构风格设计自己的系统。REST适用于跨越多个组织的长期基于网络的应用程序。如果您认为不需要约束，请不要使用它们。

选择了构成REST体系结构样式的约束作为它们引入的属性。如果这些属性对您的用例而言并不有价值，那么您绝对应该考虑删除相应的约束。

机器到机器变得困难的地方是，您已经失去了人类模糊匹配表示形式所提供的语义的能力。客户只需要了解媒体类型就可以解决问题，但通常我们需要一个人来寻找语义线索以获取含义。

schema.org是创建机器可读词汇的一项工作；机器代理使用客户端找到语义提示，并运用其自身对含义的理解来选择要采取的正确操作。

但这是工作；您需要投资开发资源的机器友好表示形式，并确保这些表示形式前后兼容，以便可以独立开发客户端。

当单个组织同时控制客户端和服务器时，这种独立性的好处要小得多，在这种情况下，约束可能不是适当的体系结构选择。

不，“完全REST”不是那么好。

缺乏在其API中实现HATEOS的人员，以及用于特定调用的HTTP动词的无休止的争论就证明了这一点。

但是您必须认识到为什么REST如此流行。在采用之前，有各种疯狂的复杂协议，例如ebXML和SOAP，涉及确认，超时，对话ID和状态。

启动并运行这些内容，然后进行说明 api使用者它们是一项艰巨的任务。“为什么我不只是在查询字符串中使用我想要的ID进行GET，然后您将数据发送给我？” 是一个显而易见的普遍问题。

然后第二个问题是XML，javascript无法理解它，架构是个麻烦，最终您将得到庞大的txt文件，其中大多数文件由组成<MyLongObjectName>。因此人们开始改用JSON。

现在REST有一些狂热之处，但是由于规则如此含糊，因此它并不能阻止您打开可用的API，该API非常简单，消费者可以在不花6个月的时间就“得到它”并使用它。处理。

要注意的是，Roy不是大多数REST原理的原始发明者，他汇集了许多已知的原理，这些原理在以前的系统中可以解决各种特定问题。REST只是在单个体系结构中应用这些原理的自然结论。

甚至在Roy Fielding撰写有关REST的论文之前，就已经围绕后来被称为REST的原理设计了HTTP。在他的论文总结中，他写道：

在Internet工程任务组内部，我们开始定义现有的超文本传输​​协议（HTTP / 1.0）[19]并为HTTP / 1.1 [42]和统一资源标识符（URI）[21]的新标准设计扩展。 ]，我认识到需要建立一种万维网应该如何工作的模型。这种在整个Web应用程序中进行交互的理想化模型（称为代表性状态转移（REST）体系结构样式）成为现代Web体系结构的基础，它提供了可以识别现有体系结构中的缺陷并进行扩展的指导原则。部署前经过验证。

REST和HATEOS非常适合解决以下问题：

REST是一组协调一致的体系结构约束，试图最小化延迟和网络通信，同时最大程度地提高组件实现的独立性和可伸缩性。这是通过在其他样式集中在组件语义上的连接器语义上设置约束来实现的。REST支持交互的缓存和重用，组件的动态可替换性以及中介程序的动作处理，从而满足Internet规模的分布式超媒体系统的需求。

但是，应该指出，Web和REST不一定适合所有问题：

同样，可以将提议的扩展与REST进行比较，以了解它们是否适合该体系结构。如果不是这样，将功能重定向到与更适用的体系结构样式并行运行的系统会更有效。

因此，如果您的问题是“ REST和HATEOAS是否是Web服务的良好体系结构？” 那么答案就是“是的，这是Web服务的良好架构”。实际上，问题在于人们是否试图通过将其改写为Web约束来解决的所有问题，实际上确实应该首先是Web服务。

有许多API确实不适合REST。不需要REST旨在解决的那种可扩展性的API，不会被可能独立发展的多个组织使用，并且不需要长期存在；对于这些问题，REST约束只是束缚。

但是实际上是否有任何理由认为REST是该领域的理想架构？更具体地说，是否有任何证据表明HATEOAS是机器对机器通信的有益设计原则？

证据是Web在解决许多人的问题上的成功。REST是一种混合架构，它结合了许多以前的架构样式的设计。许多问题域并没有Web的所有要求，也不需要服从REST的所有约束才能表现良好。这就是为什么有许多成功的体系结构仅通过应用REST的某些部分而不能应用其余部分的方式就能很好地工作的原因。例如，HATEOAS和统一接口是API经常跳过的原理，不需要跨越组织边界和弃用期相对较短的系统。

在Fielding关于Adobe Experience Manager的演示中：

REST不是架构！

休息是一种建筑风格，是互联网上存在的不同建筑的抽象。

REST是设计约束的积累，可以诱发建筑属性

REST是一个流行语，每个人都希望拥有RESTful API。实际上，当人们面临REST约束时，他们放弃了其中一些约束，因为应用这些约束没有必要或没有好处。

如您所述，当客户端是Web浏览器时，HATEOAS很有用。当客户端是移动应用程序时，可能没有那么多。这将是一个很好的实践，但是设计这样的应用程序也会产生成本，以至于举个例子，移动应用程序团队和后端团队只是同意放弃该约束。之所以这样说是有道理的，因为两个团队并不是因为他们为同一家公司工作而松散地耦合在一起。

AEM中的REST

如果您要创建另一个服务器使用的服务，则xmlrpc是正确的选择。如果您想要的是瘦客户端或低功耗设备..或未知客户端通过开放Internet使用的服务，则可以考虑使用json进行休息。但是请记住，与xml相比，json是用于指定常规数据的劣等符号。