任何人都可以解释Swagger和HATEOAS之间的区别。我可以搜索很多次，但没有哥们可以解释这两个方面的正确详细答案。
Swagger和HATEOAS IMO之间的主要区别在于，接受的答案中没有涉及，Swagger仅用于RPC'esque API。然而，这些API实际上几乎与REST无关。
还有一种普遍的误解，即通过HTTP交换的任何内容都是自动RESTful（〜符合REST架构风格），但事实并非如此。 REST只定义了一组约束，这些约束不是选项或选项，而是必需的。从开始到结束。不是RESTful没有错，但是这样的架构REST是错误的。
Swagger描述了可以在端点上执行的操作以及需要发送到服务的有效负载（包括报头和预期的表示格式），还描述了客户端可能期望作为响应的内容。这允许Swagger既可以用作API的文档也可以用作API的测试框架。由于Swagger与API的紧密耦合，它的行为很像典型的RPC服务描述，即类似于SOAP中的WSDL文件或RMI或CORBA中的stub或skeletton类。如果端点发生更改或者有效负载中的某些内容发生更改，则针对Swagger文档实施的客户端可能会随着时间的推移而重新引入典型RPC实现所具有的相同问题。
另一方面，REST和HATEOAS专为解散和进一步发展而设计。 REST不是一种协议，而是一种体系结构风格，它描述了分布式系统中客户端和服务器之间的交互流。它基本上采用了使Web成功并将其转换为应用层的概念。因此，适用于可浏览Web的相同概念也适用于REST。因此，HATEOAS（链接，链接关系和链接名称的使用和支持）的行为与Web类似，这也不奇怪。
在设计REST体系结构时，考虑一个状态机是有益的，其中服务器提供客户端进行进一步操作所需的所有信息。 AsbjørnUlsberg在2016年举行了一场精彩的演讲，在那里他explains affordances and how a state machine might be implemented through HATEOAS。除了通用或标准化的媒体类型和关系名称之外，不需要带外知识来进一步与服务交互。在Asbjørn谈到的烤面包机示例中，烤面包机可能具有状态off，on，heating和idle，其中转动烤面包机将导致从off到on的状态转换，然后过渡到heating直到某个温度达到状态转换到idle并在idle和heating之间切换，直到烤面包机关闭。
HATOAS将向客户提供有关当前状态的信息，并包括客户可以调用以转换到下一状态的链接，即再次关闭烤面包机。这里要强调的是，服务器提供客户端，客户端可能会执行下一步操作。客户端实现者无需查阅任何专有API文档，以便客户端能够与REST服务进行交互。此外，URI不必具有意义或旨在传达语义表达结构，因为客户端将通过链接关系名称确定调用该URI是否有意义。这样的关系名称由IANA指定，通过诸如Dublin Core或schema.org的常用方法或作为extension attributes的absolut URI指定，其可能指向人类可读的描述，其进一步可能通过鼠标悬停工具提示等传播给用户。 。
我希望您可以自己看到Swagger只需要描述RPC Web-API而不是遵循REST架构设计的应用程序。通过REST API交换的消息应包括客户端在下一次状态转换时做出明智选择所需的所有信息。因此，将这样的消息流和交互设计为状态机是有益的。
Swagger：Swagger帮助整个API生命周期的开发，从设计和文档到测试和部署。 [参考swagger.io]
HATEOAS：超媒体作为应用程序状态的引擎
Ion Form是一个Collection对象，其中value成员数组包含Form Fields。 Ion Forms确保可以自动发现支持数据提交的资源转换（链接）（通俗地称为HATEOAS）。 [请参阅https://ionspec.org/]
一个是支持API设计和测试的框架，另一个是API设计架构。