rest post put_REST / HTTP方法：POST与PUT与PATCH

红太狼 2023-02-25 05:58 41阅读 0赞

rest post put

每个HTTP请求都包含一个*方法* （有时称为*verb* ），该方法指示对标识的资源执行的操作。

在构建RESTful Web服务时，HTTP方法POST通常用于创建资源，而PUT用于资源更新。 尽管在大多数情况下这很好，但使用PUT进行资源创建也是可行的。 PATCH是资源更新的替代方法，因为它允许部分更新。

一般来说，我们可以说：

*  POST请求在服务器定义的URI上创建子资源。 POST也用作常规*处理*操作
 *  PUT请求在客户端定义的URI处创建或替换资源
 *  PATCH请求在客户端定义的URI上更新资源的一部分

但是，让我们进一步研究细节，看看如何在HTTP规范中定义这些动词。 这里的相关部分是[HTTP RFC（2616）的][HTTP RFC_2616]第9节。

## 开机自检 ##

RFC将POST的功能描述为：

> POST方法用于请求源服务器接受请求中包含的实体作为请求行中Request-URI标识的资源的新下属。

这允许客户端创建资源而无需知道新资源的URI。 例如，我们可以向*/ projects*发送POST请求以创建一个新项目。 服务器现在可以将项目创建为*/ project*的新下属，例如： */ projects / 123* 。 因此，在使用POST进行资源创建时，服务器可以确定新创建的资源的URI（通常是ID）。

服务器创建资源时，它应以201（已创建）状态代码和一个指向新创建资源的*Location*标头进行响应。

例如：

请求：

POST /projects HTTP/ 1.1  Content-Type: application/json  { 
         "name" : "my cool project" , 
         ...  }

响应：

HTTP/ 1.1 201 Created  Location: https: //cool.api.com/projects/123

POST不是[幂等的][Link 1] 。 因此，多次发送相同的POST请求可能会导致创建多个资源。 根据您的需求，这可能是一个有用的功能。 如果没有，则应该进行一些验证，并确保仅根据某些自定义条件（例如*，项目名称必须唯一* ）创建一次资源。

RFC还告诉我们：

> POST方法执行的操作可能不会导致可以由URI标识的资源。 在这种情况下，适当的响应状态是200（确定）或204（无内容），这取决于响应是否包括描述结果的实体。

这意味着POST不一定需要创建资源。 它也可以用于执行一般操作（例如，开始批处理作业，导入数据或处理某些操作）。

## 放 ##

POST和PUT之间的主要区别是请求URI的含义不同。 HTTP RFC说：

> POST请求中的URI标识将处理封闭实体的资源。 \[..\]相反，PUT请求中的URI标识请求\[..\]内的实体，并且服务器不得尝试将请求应用于其他资源。

对于PUT请求，客户端需要知道资源的确切URI。 我们无法将PUT请求发送到*/ projects，*并且期望在*/ projects / 123*处创建一个新资源。 相反，我们必须将PUT请求直接发送到*/ projects / 123* 。 因此，如果我们要使用PUT创建资源，则客户端需要知道（如何生成）新资源的URI / ID。

在客户端能够为新资源生成资源URI / ID的情况下，PUT实际上应优先于POST。 在这些情况下，资源创建通常是[幂等的][Link 1] ，这是对PUT的明确提示。

可以使用PUT创建和更新资源。 因此，将PUT请求发送到*/ projects / 123*可能会创建项目（如果该项目不存在）或替换现有项目。 HTTP状态代码应用于通知客户端资源是否已创建或更新。

HTTP RFC告诉我们：

> 如果创建了新资源，则原始服务器务必通过201（已创建）响应通知用户代理。 如果修改了现有资源，则应发送200（确定）或204（无内容）响应代码以指示请求已成功完成。

一般来说，如果确切的资源URI是已知的并且操作是[幂等的][Link 1] ，则PUT通常是比POST更好的选择。 在大多数情况下，这使PUT成为更新请求的理想选择。

但是，对于资源更新，应该记住一个怪癖。 根据RFC，PUT应该用新资源替换现有资源。 这意味着我们无法进行部分更新。 因此，如果我们要更新资源的单个字段，则必须发送包含完整资源的PUT请求。

## 补丁 ##

HTTP PATCH方法在[RFC 5789中][RFC 5789]定义为对前面提到的HTTP RFC的扩展。 当使用PUT替换现有资源时，使用PATCH对资源进行部分修改。

引用RFC：

> 使用PATCH \[..\]，封闭的实体包含一组指令，这些指令描述了应如何修改当前驻留在原始服务器上的资源以产生新版本。 PATCH方法影响由Request-URI标识的资源，并且可能对其他资源也有副作用。

因此，类似于POST的PATCH也可能会影响请求URI所标识资源以外的资源。

通常，PATCH请求使用与应更新的资源相同的格式，而忽略了不应更改的字段。 但是，不必一定是这种方式。 也可以使用单独的*补丁格式* ，该*格式*描述了如何修改资源。

PATCH既不[安全也不是幂等][Link 1] 。

也许您想知道在哪些情况下部分资源更新不是幂等的。 这里的一个简单示例是将项目添加到现有列表资源中，例如将产品添加到购物车中。 多个（部分）更新请求可能会将产品多次添加到购物车中。

> 翻译自: [https://www.javacodegeeks.com/2020/02/rest-http-methods-post-vs-put-vs-patch.html][https_www.javacodegeeks.com_2020_02_rest-http-methods-post-vs-put-vs-patch.html]

rest post put

[HTTP RFC_2616]: https://tools.ietf.org/html/rfc2616#section-9
[Link 1]: https://www.mscharhag.com/api-design/http-idempotent-safe
[RFC 5789]: https://tools.ietf.org/html/rfc5789
[https_www.javacodegeeks.com_2020_02_rest-http-methods-post-vs-put-vs-patch.html]: https://www.javacodegeeks.com/2020/02/rest-http-methods-post-vs-put-vs-patch.html