我发现有必要了解为什么在 URI 中包含动作动词会违反 URI 语法的 REST 协议？当我阅读下面的文章时，我感觉到太多人对动词发出了太多的噪音，他们应该对内容类型发出更多的噪音：
在一个完美的世界中，客户端浏览器都将支持 GET、POST、PUT 和 DELETE 进行请求操作。但是，仅支持 GET 和 POST，这意味着我们无法通过在 URL 中使用常见的动作动词（如查看、创建、编辑和删除）来识别应该是 PUT 和 DELETE 的操作。
这如何违反 REST 架构原则的精神，您在 URL 中添加“删除”之类的内容而不是使用“删除”时遇到的障碍是什么？
围绕 URI 提供指导的唯一正当理由是鼓励正确使用 REST 动词。如果请求执行的操作与客户端根据 HTTP 标准的期望一致，那么 url 包含什么实际上并不重要。
基于名词命名 url 可以很自然地创建与 GET、PUT、POST 和 DELETE 的预期目的一致的行为。
当您在 URL 中放置动词时，它会变得非常混乱，因为 http 动词通常会与 URL 中的动词有矛盾的行为。REST 规则说您必须尊重 HTTP 动词，但通常 url 更具描述性，因此可能会产生误导。
浏览器仅支持 HTTP 动词的子集这一事实并不重要，因为即使您确实可以完全访问所有 HTTP 动词，您仍然需要能够对其他动词建模，例如 print、close、confirm、cancel。
在谈论 REST 实现时，人们需要更多地关注内容类型而不是 URL 结构，这绝对是正确的。
让您的 URL 引用名词不是 REST 约束，而是鼓励人们陷入成功的深渊。
REST 不是一种协议，而是一种风格。因此，您可以自由地做任何符合您要求的事情。
如果可能，首选 HTTP 动词，因为它们是 HTTP 协议的一部分并且是这样的标准。它还允许您在标准 Web 服务器上使用现有的安全和缓存层，而无需编写任何定制的中间件。
REST 建议我们应该拥抱 HTTP，而不是像 SOAP、RPC 或 CORBA 那样添加抽象层。添加额外的动词，或者将它们添加到 URL 中可以被视为一种抽象，尽管它是轻量级的。
但是，正如您正确提到的那样，这些浏览器或某些版本的 Flash 并没有得到一致的支持。因此，如果您从客户端访问，则可能需要将它们放在现实世界中的 URL 中。
您应该仔细查看这一点，因为在对 URL 执行 DELETE/PUT 时可能存在严重的安全问题。
我建议动词 GET POST PUT 和 DELETE 几乎适合任何需要。您不应该需要任何新的动词或响应代码，因为这些都是通用的。在请求和响应数据中添加更多信息。
查看这篇 SO 文章以获取更多信息： 了解 REST：动词、错误代码和身份验证