PUT

PUT 方法请求创建目标资源的状态，或用请求消息有效负载中包含的表示所定义的状态进行替换。给定表示的 PUT 成功将表明，对同一目标资源的后续 GET 将在 200（OK）响应中发送等效的表示。但是，并不能保证这种状态变化是可观察到的，因为在收到任何后续 GET 之前，目标资源可能会被其他用户代理并行处理，或者可能会被原服务器进行动态处理。

如果目标资源没有当前表示，而 PUT 成功创建了一个，那么源服务器必须通过发送 201（创建）响应来通知用户代理。

如果目标资源确实有一个当前表示，并且该表示已根据所附表示的状态成功修改，那么源服务器必须发送 200（OK）或 204（无内容）响应，以表示请求已成功完成、

源服务器应验证 PUT 表示是否与服务器对目标资源的任何约束一致，这些约束不能或不会被 PUT 更改。当源服务器使用与 URI 相关的内部配置信息来设置 GET 响应的表示元数据值时，这一点尤为重要。当 PUT 表示法与目标资源不一致时，源服务器应该通过转换表示法或更改资源配置来使它们保持一致，或者通过包含足够信息的适当错误消息来解释表示法不合适的原因。建议使用 409（冲突）或 415（不支持的媒体类型）状态代码，后者专门针对 Content-Type 值的限制。

例如，如果目标资源被配置为始终具有 "text/html "的 Content-Type，而被 PUT 的表示具有 "image/jpeg "的 Content-Type，则源服务器应执行以下操作之一：

• a. 重新配置目标资源，使其符合 "text/html "和 "image/jpeg "的 Content-Type。重新配置目标资源，以反映新的媒体类型；
• b. 将 PUT 表示转换为与资源一致的格式，然后将其保存为新的资源状态；或者，
• c.拒绝请求，并给出 415（不支持的媒体类型）响应，表明目标资源仅限于 "text/html"，其中可能包括指向适合新表示法的其他资源的链接。除了通过 HTTP 提供的接口外，它没有定义资源在任何意义上的含义。它没有定义如何 "存储 "资源状态，也没有定义这种存储如何因资源状态的改变而改变，更没有定义源服务器如何将资源状态转换为表示形式。

  源服务器不得在成功响应 PUT 时发送验证器标头字段（第 7.2 节），例如 ETag 或 Last-Modified 字段，除非该请求的表示数据在保存时未对主体应用任何转换（即资源的新表示数据与 PUT 请求中接收到的表示数据完全相同），并且验证器字段值反映了新的表示。通过这一要求，用户代理可以了解其内存中的表示主体何时会因 PUT 而保持最新，从而无需再次从源服务器中检索，并且在响应中接收到的新验证器可用于未来的条件请求，以防止意外覆盖（第 5.2 节）。POST 请求中的目标资源旨在根据资源自身的语义来处理所括弧的表示，而 PUT 请求中的所括弧表示被定义为替换目标资源的状态。

  对 PUT 请求的正确解释假定用户代理知道所需的目标资源。在收到状态更改请求后，代表客户端选择适当 URI 的服务应使用 POST 方法而不是 PUT 方法来实现。如果原服务器不对目标资源进行所请求的 PUT 状态更改，而是希望将其应用于不同的资源（例如，当资源已被移动到不同的 URI 时），那么原服务器必须发送适当的 3xx（重定向）响应；用户代理可自行决定是否重定向请求。例如，一篇文章可能有一个用于标识 "当前版本"（一种资源）的 URI，该 URI 与标识每个特定版本的 URI（曾与当前版本资源共享相同状态的不同资源）是分开的。因此，对 "当前版本 "URI 的成功 PUT 请求除了会改变目标资源的状态外，还可能创建一个新的版本资源，并可能导致在相关资源之间添加链接。

  允许对给定目标资源进行 PUT 的源服务器必须对包含 Content-Range 标头字段（[RFC7233] 第 4.2 节）的 PUT 请求发送 400（错误请求）响应，因为有效载荷很可能是部分内容，而这些内容被错误地作为完整表示进行了 PUT。部分内容更新可以通过针对单独标识的资源（该资源的状态与较大资源的部分内容重叠），或通过使用专门为部分更新定义的不同方法（例如 [RFC5789] 中定义的 PATCH 方法）来实现。如果一个成功的 PUT 请求通过了为有效请求 URI 存储了一个或多个响应的缓存，那么这些存储的响应将失效（请参阅 [RFC7234] 第 4.4 节）。