它是否符合HATEOAS？获取具有不同结果的相同地址

问题描述：

当此调用每次返回不同的资源时，它是否符合HATEOAS要求通过GET /resources公开资源？例如，根据某些内部算法在客户端之间分配资源，这意味着我不希望每个客户端都总是收到相同的资源（假设我编写了“当天的短语”服务器并随机分配它们）：它是否符合HATEOAS？获取具有不同结果的相同地址

第一次调用：GET /资源

200 OK 
{ 
    "_links" : { "self" : "/resources/1" }, 
    "data" : "foo" 
}

第二个电话：GET /资源

200 OK 
{ 
    "_links" : { "self" : "/resources/2" }, 
    "data" : "bar" 
}

还是更提供GET /resources/chooser返回links对象到具体资源并进行第二次调用？

GET应该是幂等的 - 请参阅https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods – Squidly 2014-12-02 14:52:29

根据您的链接 “幂等是指请求完成后系统的状态，因此，服务器需要（例如删除一条记录），或者它返回的响应代码在后续请求中可能会有所不同“ – 2014-12-02 14:54:52

您误解了它 - 指的是'PUT'＆'DELETE'。'GET'请求'不应该有副作用，除了相对无害的影响，如日志记录，缓存，横幅广告的投放或增加web计数器。'这里的网站柜台是跟踪访客数量的东西。 – Squidly 2014-12-02 15:02:16

答

HATEOAS是关于以下链接。因此，除非您将这些操作（除了获取API根）暴露为元数据的链接（例如您的示例中的“self”），否则它将满足HATEOAS约束条件。关于URI结构没有标准，只是建议。例如，为命名资源路由呼叫比较容易。请注意，对于REST客户端，URI结构并不重要，因为它会检查链接元数据以决定是否要遵循链接。

在你当前的例子中，/resources应该有一个自我描述性的元数据，例如rel=chooser或类似的东西。所以客户会知道它是什么。我认为您的URI结构违反了URI标准，因为路径描述了URI的分层部分，但在当前情况下，在/resources和/resources/1,/resources/2 URI之间没有层次结构。所以，如果你想创建和别名或选择“选择器”的话，使用/resources/chooser或/resources?chooser=true要好得多。

有一个[RFC for URI Templating]（https://tools.ietf.org/html/rfc6570） – renatoargh 2014-12-02 15:24:06

@renatoargh是的，有，但它与URI结构无关。例如。 'resources/adsfgf432342'，'cars/3546473'，'cars？id = 3546473'可以表示完全相同的东西。您可以使用URI模板来描述结构模板。 – inf3rno 2014-12-02 15:26:15

同意。至少它是阅读的起点！ :) – renatoargh 2014-12-02 15:28:37

答

要回答您的直接问题，假设/ resource是您的应用程序的入口点，或者您有一个链接到/ resource的根资源，它肯定符合HATEOAS约束。

问如果这是RESTful体系结构还是有点棘手。有一件事是你必须绝对表明结果不可缓存。使用HTTP这将是一个HTTP头。这是假设每个/资源请求会得到一个新的资源...也许同一个用户获得相同的资源..你可以允许缓存。

我一直对GET的idempotence感到困惑。您可以使用GET进行良好的搜索，如果它们更新了相同的GET，则可能会改变结果。当然，这是改变国家的其他东西......但我记得读到他们会根据结果的点击率改变排名..这也是一个GET ...所以??

如果它是我的API，并且仅仅发出POST请求并不是什么大事，那么我可能会使用POST和406一个GET。如果我真的需要GET，我不会太担心。

它是否符合HATEOAS？获取具有不同结果的相同地址

相关推荐