REST HATEOAS（成熟度等级3）有多么重要？
我参与了一个项目，一些高级团队成员认为REST API必须符合HATEOAS标准，并实施所有Richardson的成熟级别（ http://martinfowler.com/articles/richardsonMaturityModel.html ）！
AFAIK大多数REST实现不符合HATEOAS标准，应该有更多人不这样做的充分理由。 我可以想到的原因，如增加复杂性，缺乏框架（服务器和客户端），性能问题和…
你怎么看？ 你有没有与HATEOAS在现实世界项目中的经验？
REST社区没有人说REST很简单。 HATEOAS只是增加REST架构难度的一个方面。
由于你所有的原因，人们不会做HATEOAS：这很困难。 它增加了服务器端和客户端的复杂性（如果你真的想从中受益的话）。
然而，数十亿人今天体验了REST的好处。 你知道亚马逊的“结帐”url是什么吗？ 我不。 不过，我可以每天结账。 url有变化吗？ 我不知道，我不在乎。
你知道吗？ 任何写过屏幕的人都会抄袭亚马逊自动化客户端。 有人可能会苦苦地嗅探networkingstream量，阅读HTML页面等，以find什么链接调用何时何地有效载荷。
一旦亚马逊改变了内部stream程和url结构，这些硬编码的客户端就失败了 – 因为链接断了。
然而，休闲的网上冲浪者却能够整天购物，而且几乎一帆风顺。
这就是REST的行动，它只是增强了人类，能够解释和直观的基于文本的界面，用购物车识别一个小graphics，并指出实际意义。
大多数人写软件不这样做。 大多数写自动化客户的人都不在乎。 大多数人发现，当他们破坏时，修复客户比修改应用程序不打破首先更容易。 大多数人根本没有足够的客户。
如果您正在编写一个内部API来在两个系统之间进行通信，并通过专家技术支持与stream量双方的IT部门之间进行沟通，谁能够快速，可靠地与变更进行沟通，REST将为您购买任何东西。 你不需要它，你的应用程序不够大，而且它的寿命不够长。
拥有大量用户群的大型网站确实存在这个问题。 当他们与系统交互时，他们不能要求人们改变他们的客户代码。 服务器开发时间表与客户端开发时间表不一样。 对API的突然变化是所有人都无法接受的，因为它会干扰双方的stream量和操作。
所以，像这样的操作很可能从HATEOAS中受益，因为它更容易版本化，更老的客户端更容易迁移，更容易向后兼容。
一个将大部分工作stream委派给服务器的客户端，对服务器更改的结果要比不支持的客户端更健壮。
但大多数人不需要这种灵活性。 他们正在为2个或3个部门编写服务器代码，这都是内部使用。 如果发生故障，他们会修复它，并且已经考虑到了它们正常的操作。
无论是来自REST还是其他任何方面，灵活性都会带来复杂性。 如果你想简单，快速，那么你就不会变得灵活，你只是“做”而已。 当你添加抽象和解引用到系统，然后东西变得更困难，更多的锅炉板，更多的代码来testing。
大部分的REST不符合“你不需要它”的要点。 当然，直到你做。
如果你需要它，然后使用它，并使用它，因为它的布局。 REST不是通过HTTP来回推送东西。 它从来没有，这是比这更高的水平。
但是，当你确实需要REST，并且使用REST的时候，HATEOAS是必须的。 它是软件包的一部分，是什么使它工作的关键。
是的，我在API中使用了超媒体的一些经验。 以下是一些好处：
-
可开发的API：这可能听起来微不足道，但不要低估可探索API的力量。 浏览数据的能力使客户开发人员更容易构buildAPI及其数据结构的心理模型。
-
内联文档：使用URL作为链接关系可以将客户端开发人员指向文档。
-
简单的客户端逻辑：简单地跟踪URL而不是自己构build的客户端应该更容易实现和维护。
-
服务器取得了URL结构的所有权：超媒体的使用删除了客户端对服务器使用的URL结构的硬编码知识。
-
将内容卸载到其他服务：将内容卸载到其他服务器（例如CDN）时，需要使用超媒体。
-
使用链接进行版本控制：超媒体有助于版本化API。
-
相同服务的多种实现：当同一服务的多个实现存在（并且一个客户端需要访问多个实例）时，超媒体是必需的。
您可以在这里find这些重点的深入解释： http : //soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html
（这里有一个类似的问题： https : //softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas我已经给出了相同的解释）
我认为一个API可以被称为RESTful，即使应用程序的客户端不遵循HATEOAS原则。 在大多数情况下，客户必须违反HATEOAS才能满足可用性要求。 让我解释。
HATEOAS不仅对应用程序的服务器端进行约束，而且还在客户端进行约束。 客户端不应该假定资源具有超出媒体types定义的结构的特定结构。 服务器应该提供一个支持这样的客户端的API。
现在，假设我们已经实现了这一点。 应用程序的客户端现在是非常通用的，但是很有可能用户体验是不好的，因为如果没有任何有关资源语义的知识，就无法调整资源的expression方式来反映这些语义。 如果资源'car'和资源'house'具有相同的媒体types（例如application / json），那么它们将以相同的方式呈现给用户，例如属性表（名称/值对）。
但是，没关系，我们的API真的是RESTful。
现在，假设我们在这个API之上构build了第二个客户端应用程序。 这第二个客户违反了HATEOAS的想法，并且有关于资源的硬编码信息。 它以不同的方式显示汽车和房子。
API仍然可以被称为RESTful吗？ 我想是这样。 其客户之一违反HATEOAS不是API的错。
我build议构buildRESTful API，即在理论上可以实现通用客户端的API，但是在大多数情况下，为了满足需求，您需要一些关于客户端资源的硬编码信息。 尽pipe如此，尽可能less地使用硬编码来减less客户端和服务器之间的依赖关系。
我在我的REST实现模式中包含了一个名为JAREST的HATEOAS部分 。
我在一些真实的项目中使用了HATEOAS，但是与Richardson的解释不同。 如果这是你的老板想要的，那么我想你应该这样做。 我拿HATEOAS来表示你的资源应该包含一个HTML文档types，超链接到相关的资源和HTML表单来公开GET以外的动词的function。 （这是当接受types是文本/ HTML – 其他内容types不需要这些额外的。）我不知道在你的整个应用程序中的所有REST资源必须粘在一起的信仰来自哪里。 一个networking应用程序应该包含多个可能与之直接相关的资源。 或者为什么认为XML，JSON和其他types需要遵循这一点。 （HATEOAS是特定于HTML的。）
