HTTP 方法

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#section-4.3.3，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#section-4.3.1 声明 GET 是信息检索的主要机制，也是几乎所有性能优化的重点。

从理论上讲，HTTP 请求体允许所有方法，但 TRACE 除外，但是它们不常用于 PUT、POST 和 PATCH 之外的方法。 因此，它们可能未被某些客户端框架正确支持，您不应允许 GET、DELETE、TRACE、OPTIONS 和 HEAD 方法的请求体。