为什么不为请求体指定架构？

Question

这方面的一个问题已经存在，但更多的是以科技为中心，而且没有答案：表示HATEOAS链接上的请求主体

我喜欢哈提亚。我喜欢在我的前端使用它，通过检查链接是否存在来检查是否可以执行某些操作，而不是有业务逻辑。

但我不明白的是，HATEOAS在其他场景中是如何真正有用的呢?如果您有一个"AddItemToBasket“链接，它需要一个包含一些属性的请求体。前端仍然需要知道这个请求体是什么样子。但哈特奥没有告诉你这个。

这意味着您仍然依赖于API知识。我认为很多应用程序都用生成的API客户机/graphql来解决这个问题，但这使得HATEOAS很难推销。

如果我们不能使用URL和http方法，为什么要使用，因为它不能提供完整的图片。

Answer 1

REST基于标准(统一接口约束)，目前还没有标准的方法来实现。有一个九头蛇W3C WorkGroup正在编写关于如何描述超媒体API的标准。他们使用RDF，像schema.org这样的标准语音，您可以编写他们称之为文档的API特定的词汇表。就我所理解的它们的模型而言，您可以在文档中为超链接表示的操作提供参数。例如，您可以使用XSD向参数中添加诸如数字等约束。编写这种正式文档比通常需要付出更多的努力，据我所知，目前还没有能够从中获益的普通REST客户端，因此目前编写这样的API没有多大意义，但如果您愿意的话，这是可能的。

至于为什么要使用HATEOAS，它使您的API具有灵活性和向后兼容性。例如，如果某人没有操作的权限，您就不会在响应中为其发送超链接。您总是可以添加新的操作，而现有的客户端不需要支持它们，他们可以只关注他们已经知道的内容，并且不会因为添加了额外的东西而崩溃。他们不需要知道URI结构和方法，如果它们只依赖于操作类型和参数，则可以自由地更改URI结构和方法。