RESTful HATEOAS客户端URL

Question

我有理由相信我理解HATEOAS设计的服务器端 - 在响应中返回状态URL - 但我对如何设计客户端来接受这些有点困惑.

例如,我们在//somehost.com/resource/1访问资源 - 这为我们提供了资源数据和链接.我们将假设返回//somehost.com/resource的POST,表示"新"操作.现在我理解将一些数据发布到该URL创建一个新资源,并提供响应,但发布该数据的表单在哪里？我已经看到了//somehost.com/resource/1/new提供了一个POSTS到/ resource的表单的实现,但是这个URL本身包含一个动词,并且似乎违反了REST.

我认为我的困惑在于我在同一个应用程序中实现了一个RESTful API和一个客户端来使用它.

对于这种事情,有某种最佳实践吗？

Answer 1

我已经看到了//somehost.com/resource/1/new提供了一个POSTS到/ resource的表单的实现,但是这个URL本身包含一个动词,并且似乎违反了REST.

这是不正确的.包含动词的URI 本身不会违反任何REST约束.只有当URI 表示一个违反行为的动作时.如果您可以对URL执行GET请求并接收一些有意义的资源(例如"创建新资源"表单),那么这是完全RESTful 和良好实践.

我自己的API与您描述的完全一样:/{collection}/new返回一个表单./new只是一个假设的简写/new-resource-creation-form,仍然代表一个名词,只支持GET请求(HEAD,OPTIONS和TRACE不能承受).
HATEOAS禁止的是要求用户代理知道,为了创建新资源,必须添加/new到集合的名称.

基本上,如果您将API实现为(X)HTML,并且可以在浏览器中浏览它并执行所有操作(在HTML和浏览器赶上HTTP之前,非POST表单提交可能需要AJAX),那么它符合REST的超媒体约束.

EDIT从评论中提升:

只要响应否定对先验知识的任何需要,它就符合超媒体约束.如果客户端声称理解HTML,并且您发回包含指向外部样式表或javascript(无论在何处托管)的链接的响应,客户端需要能够正确呈现页面,那么可以合理地说约束得到满足.客户端应该知道如何处理它声称支持的所有媒体类型.普通的人类Web浏览器是客户端的完美示例,没有关于任何一个HTTP服务(网站)的带外知识.

只是明确地说,网站是一种HTTP服务.Web浏览器不会以不同方式处理不同的Web站点.要在亚马逊上搜索产品,您需要加载亚马逊服务端点http://amazon.com/并按照链接或填写该响应中提供的表单.为了在eBay上搜索产品,您可以加载eBay服务端点http://ebay.com/并执行相同的操作.
浏览器不事先知道搜索易趣你必须做这个,但是对于搜索亚马逊你必须做那个.浏览器是无知的.其他HTTP服务的客户端也应该是无知的.