为什么要编写RESTful API，如果他们应该使用HATEOAS？
为了掌握RESTful API的基本目的，我开始研究HATEOAS。
根据该维基百科页面，
除了对超媒体的一般理解之外，REST客户端不需要关于如何与任何特定应用程序或服务器交互的事先知识。 相比之下，在面向服务的体系结构（SOA）中，客户端和服务器通过通过文档或接口描述语言（IDL）共享的固定接口进行交互。
现在，我真的不知道应该如何工作，除非事先知道API中可用的内容，否则这会HATEOAS的既定目的。 实际上，像Swagger这样的工具是为了记录RESTful API的明确目的而存在的。
因此，尽管我明白HATEOAS可以允许Web服务指示资源的状态，但我错过了链接（哈哈），它展示了客户端应用程序如何可能找出如何处理返回的后续链接某种“固定界面”。
HATEOAS应该如何实现这一目标？
你混淆的东西。 像Swagger这样的工具并不存在用于记录RESTful API的明确目的。 它们的存在是为了记录不是RESTful的HTTP API！ 您需要这样的工具来处理不受超文本驱动的API，并将注意力集中在URI语义和方法的文档上，而不是媒体类型。 所有那些生成URI和HTTP方法列表的奇特工具与您在REST中所做的完全相反。 在此问题上引用Roy Fielding的话：
REST API应该花费几乎所有的描述性努力来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或启用超文本的标记。 用于描述在感兴趣的URI上使用什么方法的任何努力应该在媒体类型的处理规则的范围内（并且在大多数情况下已经由现有媒体类型定义）完全定义。 [这里的失败意味着带外信息正在推动交互而不是超文本。]
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
HATEOAS并不排除需要所有文件。 HATEOAS允许您将文档集中在媒体类型上。 您的应用程序应该符合底层协议 - 大多数情况下是HTTP - 并且该协议的权威性文档是客户驱动交互所需的所有内容。 但他们仍然需要知道他们正在与之交互。
例如，当你输入Stack Overflow时，你知道有用户，问题和答案。 你需要关于这些东西到底是什么的文档，但你不需要文档详细说明链接或按钮上的点击是什么。 你的浏览器已经知道如何驱动它，这就是它在其他地方的工作原理。
引用另一个答案，REST是Web本身的架构风格。 当您输入堆栈溢出时，您知道用户，问题和答案是什么，您知道媒体类型，并且网站为您提供指向它们的链接。 REST API也必须这样做。 如果我们按照人们认为应该完成REST的方式设计网页，而不是让主页有问答链接，那么我们会有一个静态文档解释为了查看问题，您必须采用URI stackoverflow .com / questions /，将id替换为Question.id并将其粘贴到浏览器中。 这是无稽之谈，但这就是许多人认为REST的原因。
根据与服务器交互的客户端的自主级别，这个问题有各种不同的答案......
让我们先看看一个人为驱动的客户端 - 浏览器。 浏览器对银行，音乐会，猫和其他任何你在网上发现的东西一无所知 - 但它肯定知道如何呈现HTML。 HTML是支持超媒体（链接和表单）的媒体类型。 在这种情况下，您只需了解通用超媒体的客户端即可获得完美的应用程序。 这里的“固定接口”是HTML。
然后，我们拥有自主客户端或“脚本”客户端，这些客户端应该与服务进行交互，而无需人为干预。 这可能是您将REST与SOA（P）进行比较时所考虑的那种客户端。 您可以在两个独立计算机系统以某种预定义方式交换数据的集成方案中找到这样的客户端。
这种自主客户当然必须达成一致才能互相交流。 问题是这个“东西”是或者不是。
在面向服务的体系结构中，客户端同意特定的URL /端点以及要在这些端点（RPC）上调用的特定“方法” - 这会在所使用的URL结构上增加耦合。 它还强制客户知道哪种方法调用什么服务 - 服务器不能更改URL，并且无法将一个“方法”从一个服务移动到另一个服务而不中断客户端。
基于REST /超媒体的系统的行为不同。 在这样的系统中，客户端和服务器同意一个通用条目URL，客户端可以在运行时查找（GET）服务文档，使用超媒体控件（如链接或表单）描述与服务器的所有可能交互。 这些超媒体控件通知客户如何与服务交互（HTTP方法和有效载荷编码）以及与服务交互的位置。 这实质上意味着我们不再有“服务”，但可能有许多不同的服务，因为客户端在运行时会被告知在哪里以及如何与它们交互。
那么客户如何知道它应该寻找哪个超媒体控件呢？ 它通过同意服务器将用来识别相关控制的一组标识符来实现。 对于链接这通常被称为“链接关系类型”。
这使我们知道服务器和客户端达成了什么样的“事情” - 它是1）支持超媒体的媒体类型，2）根服务索引URL，3）超媒体控制标识符，以及4）预期的每个控件。 在运行时，客户端会发现剩余的URL，HTTP方法和有效负载编码（例如JSON，XML或URL编码的键/值对）。
目前，超媒体API有一小部分通用媒体类型 - 梅森，HAL，Sirene，JSON集合，JSON-LD的Hydra以及其他几种。
如果你有兴趣，那么我已经在各种博客文章中介绍了这个主题：
上一篇: Why document RESTful APIs if they are supposed to use HATEOAS?
下一篇: WCF vs WEb api vs Web services for new ecommerce website