为什么Hateoas没有为请求主体指定架构
这个问题已经存在，但是更专注于技术并且没有答案：代表代表关于Hateoas Link的要求
我喜欢Hateoas。我喜欢在前端使用它来检查是否可以通过检查链接是否存在而不是拥有业务逻辑来执行一些操作。
但是我不明白的是，在其他情况下，Hateoas如何真正有用。如果您有一个“ additemtobasket”链接，该链接需要一个带有某些属性的请求主体。前端仍然需要知道该请求的身体是什么样。但是Hateoas并没有告诉您。
这意味着您仍然对API知识有依赖性。我认为许多应用程序可以通过生成的API客户端/GraphQl解决此问题，但这使Hateoas变得很难销售。
如果我们无法使用URL和HTTP方法，为什么使用Hateoas，因为它没有提供全部图片。
A question for this already exists, but is more tech focused and doesnt have answers: Representing a request body on HATEOAS link
I like HATEOAS. I love using it in my frontend to check if I can perform some actions by checking if a link exists instead of having business logic.
But what I do not understand is how HATEOAS can truly be useful in other scenario's. What if you have an "AddItemToBasket" link which would need a request body with some properties in it. The frontend would still need to know what this request body looks like. But HATEOAS doesn't tell you this.
This means you still have a dependency on API knowledge. I think lots of applications solve this problem with generated API clients/graphql, but that makes HATEOAS a hard sell.
Why use HATEOAS if we can't use the URL and http method, because it doesn't offer the full picture.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
REST建立在标准（统一接口约束）的基础上，目前没有标准方法可以做到这一点。有一个 Hydra W3C工作组编写有关如何描述HyperMedia Apis的标准。他们使用RDF，标准词汇等标准词汇，您可以编写称为文档的API特定词汇。据我了解，您可以在文档中为超链接表示的操作提供参数。您可以使用例如XSD将诸如数字之类的约束等添加到参数中。撰写这种正式文档比往常要多得多，据我了解，目前没有一般的休息客户可以从中获利，因此目前编写这样的API并没有多大意义，但是如果您愿意，可以。
鉴于为什么使用Hateoas，它使您的API柔性和向后兼容。例如，如果某人没有操作许可，则您根本不会在响应中发送超链接。您总是可以添加新的操作，而现有客户不必支持他们，他们只能专注于他们已经知道的内容，并且由于添加了额外的东西而不会破裂。他们不必知道URI结构和方法，如果他们唯一依赖的是操作类型和参数，则可以自由地改变。
REST builds on standards (uniform interface constraint) and currently there is no standard way to do this. There is a Hydra W3C WorkGroup writing a standard about how to describe Hypermedia APIs. They use RDF, standard vocabs like schema.org and you can write your API specific vocab they call documentation. As far as I understand their model you can give parameters in the documentation for operations represented by hyperlinks. You can use for example XSD to add constraints like numbers, etc. to the parameters. It takes a lot more effort than normally to write this kind of formal documentation and as far as I understand there are currently no general REST clients which could profit from these, so it does not make much sense currently to write such an API, but it is possible if you want to.
As of why to use HATEOAS, it makes your API flexible and backward compatible. For example if somebody does not have permission for an operation, you simply don't send a hyperlink for it in the response. You can always add new operations and the existing clients don't have to support them, they can just focus on what they already know and they won't break because something extra is added. They don't have to know about the URI structures and the methods, which can freely change if the only thing they depend on is the operation type and the parameters.