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