在资源上代表POST / PUT / PATCH的HATEOAS链接的最佳方法是什么？这些操作具有有效载荷，但我们没有选择在HATEOAS链接中表示有效载荷，因为它们不是预先确定的并且可能很重。那么只需指定结束点并指定操作就足够了吗？
对于使用HATEOAS POST / PUT / PATCH链接的JSON回复，我们非常感谢您提供任何示例或示例。
答案 0 :(得分：1)
链接由两个元素组成：href和rel。 href包含用于查找资源的显式URL。 rel标识当前资源与链接资源之间的关系。 rel应该用于确定可接受的HTTP方法以及如何使用链接。
以下是 RESTful Web Services Cookbook 第5.4节的引用：
链接关系类型传达链接的角色或目的。一旦客户端和服务器就这些类型的含义达成一致，客户端就可以从链接中找到并使用URI。
例如，edit是一个standard link relation explicit details，其中包含有关使用GET，PUT，POST，{{1}的详细信息}}
可以扩展链接关系，您可以添加自己的链接。
答案 1 :(得分：0)
这些操作具有有效载荷，但是我们没有选择在HATEOAS链接中表示有效载荷的选项，因为它们不是预先确定的并且可能很重？
通常的答案是，在描述所用媒体类型的描述中记录操作。
要考虑的一个参考是Atom Syndication / Atom Pub。基本思想是指定介质类型可以告诉您如何解释文档，包括对link relations的解释。
另请参阅Fielding, 2008
REST API应该花费几乎所有的描述性精力来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体定义扩展的关系名称和/或启用超文本的标记类型。在描述媒体类型的处理规则的范围内，应该完全定义用于描述在感兴趣的URI上使用哪种方法的所有工作
通常，PUT和PATCH应该非常简单-这些是远程创作方法； PUT的请求正文通常只是GET提供的表示形式的编辑版本，而PATCH只是描述编辑的另一种方式（通常使用Accept-Patch标头描述的一种媒体类型）
POST是很难的-因为POST语义具有非常宽松的约束，所以存在很多自由度。如果您无法按照顺序描述其他约束条件，则必须更加依赖于媒体类型的定义。