在资源上表示POST/PUT/PATCH的HATEOAS链接的最佳方式是什么?这些操作都有有效载荷，但我们无法选择在HATEOAS链接中表示有效载荷，因为它们不是预先确定的，而且可能很重。那么仅仅指定终点和操作就足够了吗?
任何样本或示例将非常感谢JSON响应与HATEOAS POST/PUT/PATCH链接。
链接由两个元素组成:href和rel。href包含用于定位资源的显式URL。rel标识当前资源和链接资源之间的关系。rel应该用来确定什么HTTP方法是可接受的，以及如何使用链接。
下面是引用自RESTful Web Services Cookbook第5.4节:
链接关系类型传达了链接的角色或目的。一旦客户端和服务器就这些类型的含义达成一致，客户端就可以从链接中找到并使用uri。
例如，edit是一个标准的链接关系，它有明确的细节，包括使用GET, PUT, POST, DELETE的细节。
链接关系可以扩展，您可以添加自己的。
这些操作有有效载荷，但我们无法选择在HATEOAS链接中表示有效载荷，因为它们不是预先确定的，而且可能很重?
通常的答案是在描述中记录用于表示的媒体类型的操作。
要考虑的一个引用是Atom Syndication/Atom Pub。其基本思想是，媒体类型的规范告诉您如何解释文档，包括对链接关系的解释。参见Fielding, 2008
REST API应该把几乎所有的描述性工作都花在定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有的标准媒体类型定义扩展的关系名称和/或支持超文本的标记上。描述对哪些uri使用什么方法所做的任何努力都应该完全在媒体类型 的处理规则范围内定义。
作为规则，PUT和PATCH应该非常直接——它们是远程创作方法;PUT的请求体通常只是GET提供的表示的编辑版本，而PATCH只是描述编辑的另一种方式(通常使用Accept-Patch头描述的一种媒体类型)。
POST是比较难的一个——因为POST语义有非常宽松的约束，有很多自由度。如果您不能在一行中描述额外的约束，那么您必须更加依赖媒体类型的定义。