HTTP 定义了在资源 URI 上的 METHOD 概念。
METHOD URI 操作 是否有请求体？ HEAD /foo/ID 存在 NO GET /foo/ID 读取 NO POST /foo 创建 YES PUT /foo/ID 更新 YES PATCH /foo/ID 更新（部分） YES DELETE /foo/ID DELETE NO
将 HTTP 请求方法映射到创建、读取、更新、删除 ( CRUD ) 模型只是一种方便的、但并不完整的记忆辅助。具体来说，它误解了 POST 的含义和目的。根据 RFC 7231，POST “请求目标资源根据资源自身特定的语义处理请求中包含的表示”。 这可以并且经常意味着创建，但它可能意味着许多其他事情，具体取决于资源的需要。
更广义地说，CRUD 模拟了持久存储的四个基本功能。HTTP API 并非仅仅是持久存储的代理。它可以提供对这种存储的访问，但它可以做更多的事情。
请注意，虽然 HEAD 建议用于检查资源是否存在，但相应的 GET 应该始终实现，并且应该返回相同的响应，如果适用，则添加主体。
TODO：HEAD 在我们的许多 wsgi 框架中很奇怪，你无法访问它。 弄清楚是否有任何有用的东西。
TODO：提供指导，哪些 HTTP 方法（PUT/POST/PATCH/DELETE 等）应该始终支持，哪些应该优先支持。
在选择如何更新存储的资源时，PUT 和 PATCH 意味着不同的语义。 PUT 发送完整的资源表示形式（包括未更改的字段），这将替换服务器上存储的资源。 相比之下，PATCH 接受部分表示形式，这将修改服务器存储的资源。 RFC 5789 没有指定部分表示形式。 RFC 6902 中的 JSON-patch 指定了一种以 JSON 形式发送一系列更改的方法。 一种未标准化的替代方案是接受缺失的资源字段，将其视为从服务器保存的资源状态未更改。 RFC 5789 不禁止以这种方式使用 PUT，但这种方法在处理列表或集合时可能会导致更新丢失。
在创建新资源的特定实例中，何时使用 POST 或 PUT 也可能存在混淆。 当结果资源的 URI 与请求发送到的 URI 不同，并且导致资源具有服务器生成的标识符（URI）时，应使用 POST。 在 OpenStack 环境中，这是常见的情况。 当请求发送到的 URI 与结果资源的 URI 相同时，应使用 PUT 进行资源创建。
也就是说，如果正在创建的资源的 ID 是已知的，请使用 PUT 并 PUT 到资源的正确 URI。 否则，使用 POST 并 POST 到更通用的 URI，该 URI 将响应新的资源 URI。
GET 方法仅应用于检索资源的表示形式。 它不应更改由 URI 标识的资源的任何状态，也不应更改服务器的一般状态。 RFC 7231 声明 GET 是信息检索的主要机制，也是几乎所有性能优化的重点。
理论上，所有方法（TRACE 除外）都允许 HTTP 请求体，但是它们不常用于 PUT、POST 和 PATCH 中。 因此，它们可能未被某些客户端框架正确支持，您不应允许 GET、DELETE、TRACE、OPTIONS 和 HEAD 方法的请求体。