rest - 如何处理客户端 Rest 中的每个动词权限？

Question

假设我们在这样的 URL 上有一个资源:foo.com/api/bar假设用户可能被允许获取该资源，但不允许 POST 到该资源。

我可以通过为每个动词指定不同的权限来轻松解决这个问题。但是客户端如何预先知道是否允许执行 POST？

假设我们在页面上有一个“保存”按钮，如果用户没有执行 POST 的权限，则不应启用该按钮。

我知道 HATEOAS/Hypermedia 约束，我可以将不同操作的链接列表与资源一起传递。但是 AFAIK，它不包含有关使用什么动词的信息，仅包含用于不同操作的 URL。是否有包含动词的其他变体？

如果您不想让各种元数据弄乱资源，还有其他方法吗？

Answer 1

这在 HAL 讨论论坛上被问了很多 https://groups.google.com/forum/#!forum/hal-discuss

不返回动词的事实是由您使用的超媒体格式决定的，我猜是 HAL(或者可能是 collection+json)。有些格式确实包含动词信息。

如果您愿意，HAL 实际上允许您在链接对象上包含自定义字段，但我不鼓励这样做，因为任何标准客户端都不知道如何解释它。

但我也发现这个动词最终毫无值(value)。

首先，在人类 2 机器中，用户将阅读文档。 HAL 将所有链接取消引用(通过 CURIE，因为它们目前是 naemd)到人类可读的文档，这些文档应该描述请求具有不同参数、动词、标题等的链接的效果。

下一步是为了使您的应用程序真正成为 RESTful，您应该响应所有动词……您可能只是不响应动词是 OK。对于基于 HTTP 的应用程序，返回 405 是非常合适的。返回 404 不是! 500 会更糟!您的 405 应该包括所请求资源可用的方法。

接下来，在机器 2 机器(和一些 h2m)的情况下，您的应用程序在通过 HTTP 访问时(我尽量避免在我的答案中使用 http，因为 RESTful 应用程序不一定是 HTTP..虽然我会说 101%其中)应该对资源 URL 使用 OPTIONS 方法(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)以获得可能的描述。

这是我看到很多人被绊倒的地方，OPTIONS 的响应应该是什么？人们忘记的是内容类型协商!请求者应该说出他们期望的选项信息的格式。接受:some-machine-language/xml 或 application/language+json。一些 RFC 或标准定义了这些内容类型，您的 API 可以识别它支持的格式。我建议您包括对 text/html 的支持，以便您可以返回人类可读的文档以及有关支持哪些动词的文档。这很好地涵盖了 h2m 场景。

当返回有关不受支持的方法的信息时，相同的内容类型协商可能很有用。服务器可以发送客户端可以理解的内容类型，从语义上描述允许使用哪些方法。

我想指出的最后一件事是，方法暗示了客户的意图。我想放置此资源或删除该资源。服务器应接受请求并返回指示由于该请求而发生的状态转换的响应。因此，让 API 在每个请求中识别客户端的可能意图有点愚蠢。客户端知道它想做什么，它应该尝试，如果它不能，那么它应该处理它。