Which HTTP methods match up to which CRUD methods?

Question

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?

Solution 1

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.

Solution 2

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

Solution 3

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.

Solution 4

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

Solution 5

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.

View more solutions

Comments

[Donal Fellows]

PUT and POST don't match exactly to either Update or Create; PUT is “set” (i.e., where you know the resource name beforehand and are giving the value to use) and POST is everything else. The key is to think about whether what you are doing is idempotent or not.

[stand]

+1 on the comment. The assumption of an absolute mapping between the two can be misleading. An HTTP DELETE operation to some URI, for example might simply modify (i.e. UPDATE) a server side record so that an HTTP GET operation on no longer returns a representation.

[Jim Ferrans]

+1: The distinction you make between PUT to create resources whose names (URIs) are assigned by the client and POST to create resources whose names are assigned by the server is important. See Richardson and Ruby's Restful Web Services (O'Reilly) for a discussion on it.

[Jim Ferrans]

And since PUT and DELETE aren't yet supported by web browsers, it's considered okay to "overload POST" by adding a query string argument like method=PUT or method=DELETE on the URI being POSTed.

[Piotr Dobrogost]

PUT and POST don't match exactly to either Update or Create. True but AJ described what pattern he uses.

[Boris Ivanov]

Nice analyses jcalcote.wordpress.com/2008/10/16/…

[eis]

@JimFerrans PUT and DELETE are supported by web browsers just fine, with XHR. However, in the context of HTML forms, HTML specification doesn't support them so browsers can't either.

[bh5k]

Here is a link where Martin Fowler discusses the Richardson Maturity model and summarizes it quite well: martinfowler.com/articles/richardsonMaturityModel.html

[Toddius Zho]

While not canonically mapping to a letter in CRUD, a lot of REST frameworks also use GET /entity/ to List entities of type entity. GET /entity/id will read the particular entity matching the id.

[Les Hazlewood]

PUT and POST can BOTH be used for Create and Update. I cover this here: youtube.com/watch?v=hdSrT4yjS1g&t=18m12s I also cover idempotency mandates. I hope this is helpful!

[Lawrence Dol]

Using POST for an update allows the caller to provide a partial list of properties, being one the ones they want to update.

[Trevor]

Update could also correspond to PATCH, which should represent a partial update (e.g. a single attribute on an entity). Note: support for PATCH is a bit spotty; not all server software has implemented this HTTP method.

[Admin]

What about GetAll(), GetRange()? Say you have controller with GET() POST() PUT() DELETE() methods /entity = GetAll() /entity/1 = Get(1) /entity/0/10 = GetRange(0,10) (from index 0 return 10 more)?

[Polykrom]

dalu check out stackoverflow.com/questions/6190323/… for an answer to your question.

[Sebastian Barth]

What about the other methods like PATCH and HEAD? Aren't they a part of REST?

[zerobandwidth]

This distinction between the use cases for POST and PUT is an interesting one, and should make the answer to "Which is 'create' and which is 'update'?" that much clearer. Further, with regards to the implementation of the API, it would follow that a repetitive PUT should amount to a silent no-op, whereas a repetitive POST might throw an exception if some aspect of the data being sent is supposed to remain unique in the data store that backs the application.

[Martin Spamer]

This answer & following comment raise an important point, that caution should be exercised in equating CRUD to closely (1to1) with HTTP REST semantics. This is not a canonical mapping.

[Dizzley]

As of Feb '18, be aware that PATCH is not thoroughly implemented in client and server libraries.

[d1jhoni1b]

oh ok thanks i see...would you mind to post a link/reference so i can take a look please?

[cowlinator]

@osullic, I believe the distinction between a partial update and a full update is that a partial update modifies the existing resource, while a full update discards and replaces the existing resource.