让我们假设我们在URL上有一个资源：foo.com/api/bar
并且假设可以允许用户获取该资源，但不允许POST到该资源。
我可以通过为每个动词指定不同的权限来轻松解决这个问题。 但是，如果允许客户端执行POST，客户端应如何知道？
假设我们有一个＆＃34; save＆＃34;页面上的按钮，如果用户没有权限进行POST，则不应启用该按钮。
我了解HATEOAS / Hypermedia约束，并且我可以将不同操作的链接列表与资源一起传递。 但是，AFAIK没有提供有关使用动词的信息，只针对不同的动作使用URL。 是否包含动词的其他变体？
如果您不想使用各种元数据来混淆资源，还有其他方法吗？
答案 0 :(得分：1)
在HAL讨论论坛https://groups.google.com/forum/#!forum/hal-discuss
上已经有很多问题动词未被返回的事实是您正在使用的超媒体格式的决定，我猜测它是HAL（或者可能是集合+ json）。一些格式包括动词信息。
如果您愿意，HAL实际上允许您在链接对象上包含自定义字段，但我不鼓励这样做，因为任何标准客户端都不知道如何解释这一点。
但我也发现这个动词最终毫无价值。
首先在人类2机器中，用户将阅读文档。 HAL将其所有链接解除引用（通过CURIE＆＃39; s，因为它们当前是naemd）到人类可读的文档，应描述请求具有不同参数，动词，标题等的链接的效果。
接下来关闭的是，对于你的应用程序真正的REST，你应该回应所有的动词...你可能只是没有回应动词是好的。对于基于HTTP的应用程序返回405是非常合适的。返回404不是！ 500会更糟！您的405应包括可用于所请求资源的方法。
接下来是机器2机器（以及一些h2m）的情况下你的应用程序通过HTTP访问（我试图在我的答案中避免使用http，因为RESTful应用程序不一定是HTTP ...尽管我已经＃＆ d表示101％的人应该对资源网址使用OPTIONS方法（http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html），以便了解可能的内容。
在这里，我看到很多人被绊倒，OPTIONS的回应应该是什么？人们忘记的是内容式谈判！请求者应该说出他们期望的选项信息的格式。接受：some-machine-language / xml或application / language + json。某些RFC或标准定义了这些内容类型，您的API可以识别它支持的格式。我建议您包含对text / html的支持，以便您可以返回人类可读的文档以及支持的动词。这很好地涵盖了h2m场景。
返回有关不支持的方法的信息时，相同的内容类型协商非常有用。服务器可以发送客户端可以理解的内容类型，该内容类型在语义上描述了允许的方法。
我想指出的最后一点是方法意味着客户意图。我想要PUT这个资源或删除该资源。服务器应接受请求并返回响应，指示由于该请求而发生了哪些状态转换。因此，让API识别每个请求的客户端可能的意图是有点愚蠢的。客户知道它想做什么，它应该尝试，如果它不能，那么它应该处理它。
答案 1 :(得分：0)
HTTP Verbs是纯传输协议动词。这些可能不是执行应用程序功能的正确动词，正是因为您在问题中提到的问题。因此，让我们看看我们是否可以在不使用http动词的情况下以不同方式处理使用http动词执行应用操作可能会限制我们明天，因为我们可能需要从http转移到另一个协议。
让我们举一个例子来说明。我们假设我们正在讨论使用HATEOAS更新删除应用程序。因此，在这种情况下，如果有两个产品，由URL www.abc.com/product/001和www.abc.com/product/002表示。在真正的HATEOAS情况下，如果必须查看两个产品product / 001和product / 002的响应，则显示客户端屏幕。
因此，如果对product / 001的响应具有响应product / 001 / delete，则product / 001 / change和product / 002具有响应product / 002 / Change，那么客户端将仅显示产品/ 001的删除并更改对于其他两个产品。
所以回答你的问题。通过适当地识别产品的行为，现在可以进行基于角色的行动。
我希望我已经回答了你的问题。