Create = PUT with a new URI
         POST to a base URI returning a newly created URI
Read   = GET
Update = PUT with an existing URI
Delete = DELETE

PUT可以映射到Create和Update，这取决于与PUT一起使用的URI的存在。

POST映射到Create。

更正:POST也可以映射到Update，尽管它通常用于创建。POST也可以是部分更新，所以我们不需要建议的PATCH方法。

REST的构建块主要是资源(和URI)和超媒体。在这个上下文中，GET是获取资源表示的方法(在CRUD术语中，它确实可以映射到SELECT)。

但是，您不应该期望CRUD操作和HTTP谓词之间有一对一的映射。 PUT和POST的主要区别在于它们的幂等性。POST也更常用于部分更新，因为PUT通常意味着发送资源的全新表示形式。

我建议你读一读:

http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

HTTP规范也是一个有用的参考:

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. [...] The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

The whole key is whether you're doing an idempotent change or not. That is, if taking action on the message twice will result in “the same” thing being there as if it was only done once, you've got an idempotent change and it should be mapped to PUT. If not, it maps to POST. If you never permit the client to synthesize URLs, PUT is pretty close to Update and POST can handle Create just fine, but that's most certainly not the only way to do it; if the client knows that it wants to create /foo/abc and knows what content to put there, it works just fine as a PUT.

The canonical description of a POST is when you're committing to purchasing something: that's an action which nobody wants to repeat without knowing it. By contrast, setting the dispatch address for the order beforehand can be done with PUT just fine: it doesn't matter if you are told to send to 6 Anywhere Dr, Nowhereville once, twice or a hundred times: it's still the same address. Does that mean that it's an update? Could be… It all depends on how you want to write the back-end. (Note that the results might not be identical: you could report back to the user when they last did a PUT as part of the representation of the resource, which would ensure that repeated PUTs do not cause an identical result, but the result would still be “the same” in a functional sense.)

目前(2016年)最新的HTTP动词是GET, POST, PATCH, PUT和DELETE

概述

HTTP获取-选择/请求 HTTP put - update 插入/创建 HTTP补丁——当放置一个完整的资源表示很麻烦并且占用了更多的带宽时，例如:当你必须部分更新一个列时 HTTP删除-删除

希望这能有所帮助!

如果你对设计REST api感兴趣，这是一本不错的读物!网站在线版本github资源库

我一直在寻找同样的答案，这是IBM说的。 IBM链接

POST创建一个新资源。 GET检索资源。 PUT更新现有资源。 DELETE删除资源。

一般来说，这是我使用的模式:

HTTP获取-选择/请求 HTTP put - update 插入/创建 HTTP删除-删除