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