我仍然不明白客户端在创建资源时如何知道要POST的数据。大多数教程/文章都忽略了这一点，在他们的例子中，客户似乎总是知道要发布什么（即使用带外信息）。与this示例中一样，消费者知道他必须通过设置＆lt; drink \＆gt;来下订单。他想要。
我只能想象一些方法而且我不知道它们是否有效：
1。返回空资源
客户端发现指向 / resource 的链接，其链接指向 / resource / create 和关系“create”。 GET到 / resource / create 返回一个空资源（所有属性都为空）和一个链接到 / resource / create ，关系为“post”。然后，客户端将值设置为所有属性，并将此POST发送到 / resource / create ，返回201（已创建）。这意味着CRUD操作不是位于资源端点，而是位于 / resource / create 之类的URI，并且客户端可能设置服务器忽略的属性（如服务器端设置的创建日期） ）
2。退回表格
基本上与上面相同的方法，尽管事实上不返回资源但是有关要发布哪些字段以及每个属性需要具有哪些数据类型的元信息。就像在this例子中一样。不过，创建端点不在 / resource ，而是在 / resource / create
第3。通过更新创建
对 / resource 的POST立即创建一个空资源，并返回指向该资源的链接。然后，客户端可以按照此链接更新资源，并使用必要的数据执行PUT。
那么仍然遵循HATEOAs范例的最佳方法是什么？为什么所有这些教程（甚至像实践中的REST这样的书）都忽略了这个问题？
的更新：
我最近发现Sun Cloud API似乎非常接近“理想的”REST HATEOAS API。它不仅定义了一些资源并在它们之间进行了超链接，还定义了媒体类型和版本控制。通过所有这些理论讨论，拥有一个具体的例子是非常好的。也许这可以帮助一些读者解决这个问题。
答案 0 :(得分：2)
关于REST的大多数教程和书籍都非常具有误导性，因为除了Fielding的论文本身之外，还有许多关于REST的误解和没有权威来源，这是不完整的。
REST不是CRUD。 POST不是CREATE的同义词。 POST是用于尚未通过HTTP标准化的任何操作的方法。如果它没有被HTTP标准化，它的语义由目标资源本身决定，并且必须由资源媒体类型记录确切的行为。
使用HATEOAS，客户不应依赖带外信息来驾驶交互。文档应该关注媒体类型，而不是URI和方法。人们很少能做到这一点，因为他们没有正确使用媒体类型，而是记录URI端点。
例如，在您的示例中，所有内容都具有application/xml媒体类型。这就是问题所在。如果没有适当的媒体类型，当所有内容都具有相同的媒体类型而不依赖于URI语义时，就无法记录特定于资源的语义，这会破坏HATEOAS。相反，饮料应该具有类似application/vnd.mycompany.drink.v1+xml的媒体类型，并且您对该媒体类型的API文档可以描述在使用具有rel链接的POST时会发生什么。