Which HTTP methods match up to which CRUD methods?

In RESTful style programming, we should use HTTP methods as our building blocks. I'm a little confused though which methods match up to the classic CRUD methods. GET/Read and DELETE/Delete are obvious enough.

However, what is the difference between PUT/POST? Do they match one to one with Create and Update?

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 can map to both Create and Update depending on the existence of the URI used with the PUT.

POST maps to Create.

Correction: POST can also map to Update although it's typically used for Create. POST can also be a partial update so we don't need the proposed PATCH method.

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

I Was searching for the same answer, here is what IBM say. IBM Link

> POST Creates a new resource. > GET Retrieves a resource. > PUT Updates an existing resource. > DELETE Deletes a resource.

Right now (2016) the latest HTTP verbs are GET, POST, PATCH, PUT and DELETE

Overview

• HTTP GET - SELECT/Request
• HTTP PUT - UPDATE
• HTTP POST - INSERT/Create
• HTTP PATCH - When PUTting a complete resource representation is cumbersome and utilizes more bandwidth, e.g.: when you have to update partially a column
• HTTP DELETE - DELETE

Hope this helps!

If you are interested on designing REST APIs this is an ansewome reading to have! website online version github repository

There's a great youtube video talk by stormpath with actually explains this, the URL should skip to the correct part of the video:

stormpath youtube video

Also it's worth watch it's over an hour of talking but very intersting if your thinking of investing time in building a REST api.

It depends on the concrete situation.. but in general:

PUT = update or change a concrete resource with a concrete URI of the resource.

POST = create a new resource under the source of the given URI.

I.e.

Edit a blog post:

PUT: /blog/entry/1

Create a new one:

POST: /blog/entry

PUT may create a new resource in some circumstances where the URI of the new ressource is clear before the request. POST can be used to implement several other use cases, too, which are not covered by the others (GET, PUT, DELETE, HEAD, OPTIONS)

The general understanding for CRUD systems is GET = request, POST = create, Put = update, DELETE = delete

The building blocks of REST are mainly the resources (and URI) and the hypermedia. In this context, GET is the way to get a representation of the resource (which can indeed be mapped to a SELECT in CRUD terms).

However, you shouldn't necessarily expect a one-to-one mapping between CRUD operations and HTTP verbs. The main difference between PUT and POST is about their idempotent property. POST is also more commonly used for partial updates, as PUT generally implies sending a full new representation of the resource.

I'd suggest reading this:

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

The HTTP specification is also a useful reference:

> 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,

Generally speaking, this is the pattern I use:

• HTTP GET - SELECT/Request
• HTTP PUT - UPDATE
• HTTP POST - INSERT/Create
• HTTP DELETE - DELETE

The Symfony project tries to keep its HTTP methods joined up with CRUD methods, and their list associates them as follows:

• GET Retrieve the resource from the server
• POST Create a resource on the server
• PUT Update the resource on the server
• DELETE Delete the resource from the server

It's worth noting that, as they say on that page, "In reality, many modern browsers don't support the PUT and DELETE methods."

From what I remember, Symfony "fakes" PUT and DELETE for those browsers that don't support them when generating its forms, in order to try to be as close to using the theoretically-correct HTTP method even when a browser doesn't support it.