假设我们在这样的 URL 上有一个资源：foo.com/api/bar
假设用户可能被允许获取该资源，但不允许发布到该资源。
我可以通过为每个动词指定不同的权限来轻松解决这个问题。但是，如果允许执行 POST，客户端应该如何事先知道呢？
假设我们在页面上有一个“保存”按钮，如果用户没有进行 POST 的权限，则不应启用该按钮。
我知道 HATEOAS/超媒体约束，并且我可以将不同操作的链接列表与资源一起传递。但是 AFAIK，它不携带有关使用哪些动词的信息，只有用于不同操作的 URL。是否存在包含动词的其他变体？
如果您不想用各种元数据使资源混乱，还有其他方法吗？
在 HAL 讨论论坛https://groups.google.com/forum/#!forum/hal-discuss
不返回动词的事实是您使用的超媒体格式的决定，我猜是 HAL（或者可能是集合 + json）。某些格式确实包含动词信息。
如果您愿意，HAL 实际上允许您在链接对象上包含自定义字段，但我不鼓励这样做，因为任何标准客户端都不知道如何解释这一点。
但我也发现这个动词最终毫无价值。
首先在人类 2 机器中，用户将阅读文档。HAL 将所有链接取消引用（通过 CURIE，因为它们目前是 naemd）到人类可读的文档，这些文档应该描述使用不同参数、动词、标题等请求链接的效果。
接下来是为了让您的应用程序真正成为 RESTful，您应该响应所有动词……您可能只是不响应动词没问题。对于基于 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 在每个请求中识别客户端的可能意图有点愚蠢。客户知道它想做什么，它应该尝试，如果它不能，那么它应该处理它。
HTTP 动词是纯传输协议动词。正是由于您在问题中提到的问题，这些可能不是执行应用程序功能的正确动词。所以让我们看看我们是否可以在不使用 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 则客户端将仅显示删除 product/001 并更改其他两种产品。
所以回答你的问题。通过适当地识别产品的操作，现在可以执行基于角色的操作。
我希望我已经回答了你的问题。