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.)

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,

Symfony项目试图保持其HTTP方法与CRUD方法的联合，它们的列表将它们关联如下:

从服务器上检索资源 在服务器上创建一个资源 PUT更新服务器资源 DELETE删除服务器上的资源

值得注意的是，正如他们在该页上所说，“实际上，许多现代浏览器不支持PUT和DELETE方法。”

据我所记得，Symfony在生成表单时为那些不支持PUT和DELETE的浏览器“伪造”了PUT和DELETE，以便在浏览器不支持HTTP的情况下尽量接近使用理论上正确的HTTP方法。

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.)

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

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

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

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