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

rest post put

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

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

一般来说，我们可以说：

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

但是，让我们进一步研究细节，看看如何在HTTP规范中定义这些动词。这里的相关部分是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不是幂等的。因此，多次发送相同的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。在这些情况下，资源创建通常是幂等的，这是对PUT的明确提示。

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

HTTP RFC告诉我们：