PUT方法请求用请求消息有效载荷中包含的表示定义的状态创建或替换目标资源。给定表示的成功PUT将表明，在相同目标资源上的后续GET将导致在200（OK）响应中发送等同的表示。但是没有保证状态改变可以被观察到，因为在随后的GET被接收到之前，目标资源可能被其他用户代理并行的执行动作，或者可能被源服务器动态的处理。成功的响应只按时用户代理的意图在那个时间点被源服务器实现。
如果目标资源没有当前的表示那么PUT成功的创建一个，然后源服务器必须通过发送201（创建）响应通知用户代理，如果目标资源已经有当前表示并且该表示按照包括的表示状态被成功的修改，那么源服务器必须发送一个200（成功）或204（无内容）响应来表明请求的成功完成。
源服务器应该忽略在PUT请求中接受到的未识别的头字段（即，不要将他们作为资源状态的一部分保存）。
源服务器应该确认原PUT表示与服务器对于不能或不会被PUT改变的目标资源的约束一致。当源服务器使用与URI相关的内部配置信息来为GET响应的表示的元数据设置值的时候，这会很重要。当PUT表示与目标资源不符时，源服务器应该通过转换表示或者改变资源配置使他们一致，或者以一个合适的包含足够信息以解释为什么表示是不当的错误信息进行响应。409（冲突）或者415（不支持的媒体类型）状态码是建议的，后者特定于内容类型值的约束。
例如，如果目标资源被配置为总是有Content-Type为“text/html”并且表示被PUT有Content-Type为“image/jepg”，源服务器应该执行下面一个措施：
- 重新配置目标资源以反映新的媒体类型；
- 转变PUT的表示为与被保存为新资源状态前的表示一致的格式；或者
- 以415（不支持的媒体类型）响应拒绝请求以指示目标资源被限制为“text/html”，也许保护那一个链接指向不同的资源，这个资源对于新的表示将是一个合适的目标。
HTTP没有精确的定义PUT方法如何影响超出用户代理请求的意图和源服务器响应的语义可以表达的源服务器的状态。它没有定义在任何意义上资源可能是什么，除了通过HTTP提供的接口。它没有定义资源状态如何被“存储”，或者这种存储作为一个资源状态改变的结果可能如何改变，或者源服务器如何将资源状态转换为表示。通常来说，所有在资源接口后面的实现细节都被服务器有意隐藏起来。
源服务器不得PUT的成功响应中发送验证器头字段（7.2节）（如ETag或Last-Modified字段），除非请求的表示数据被没有任何转换的应用到消息体而保存（即，资源的新的表示数据与在PUT请求中接收到的表示数据是相同的），并且验证器字段值反映了新的表示。这个要求允许用户代理知道它在内存中的表示体何时保持了当前PUT的结果，从而不需要从服务器上重新检索，并且在响应中接收到的新验证器可以被用于将来的条件请求以防止无意的复写（5.2节）。
POST和PUT方法之间的根本区别在于封闭表示的不同意图。POST请求中的目标资源意图通过资源自己的语义处理封闭表示，而PUT请求中的封闭表示被定义为替换目标资源的状态。所以，PUT的意图是幂等的，并且对中介可见，即使确切的影响只被源服务器知道。
PUT请求的正确解释假定用户代理知道哪个资源是期望的。代表客户端选择合适的URI的服务在接收到状态改变请求后应该使用POST方法而不是PUT来实现。如果源服务器不会将所请求的PUT状态更改为目标资源，而是希望将其应用于不同的资源，例如当资源移动到不同的URI时，则源服务器必须发送适当的3xx 重定向）响应；用户代理之后可能做出自己的决定是否重定向请求。
PUT请求应用到目标资源上可能对其他资源有副作用。例如，例如，一篇文章可能有一个URI，用于标识与标识每个特定版本（不同的资源在一个点上共享与当前版本资源相同的状态。）的URI不同的“当前版本”（资源）。“当前版本URI上”成功的PUT请求可能因此创建一个新版本的资源，此外改变目标资源的状态，并且可能也引起相关资源之间的链接被添加。
允许在一个给定目标资源上PUT的源服务器必须发送400（错误请求）响应给包含Content-Range头字段（RFC7233，4.2节）的PUT请求，因为负载可能是部分内容，它被错误地作为一个完整的表示被PUT。部分内容更新可以通过将单独标识的资源定位为与较大资源的一部分重叠的状态，或者使用为部分更新专门定义的不同方法（例如[RFC5789]中定义的PATCH方法）。
PUT方法的响应不可缓存。如果一个成功的PUT请求通过一个缓存，对于有效的请求URI它有一个或多个已存储的响应，那些存储的响应将成为无效的（查看RFC7234，4.4节）。
若有收获，就点个赞吧
0 人点赞
