227

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?

Drew
  • 15,158
  • 17
  • 68
  • 77

9 Answers9

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

Paul Morgan
  • 31,226
  • 3
  • 24
  • 27
  • 16
    +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 Jun 02 '11 at 04:13
  • 9
    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. – Jim Ferrans Jun 02 '11 at 04:16
  • 2
    Nice analyses http://jcalcote.wordpress.com/2008/10/16/put-or-post-the-rest-of-the-story/ – Boris Ivanov Jun 22 '12 at 17:19
  • 13
    @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. – eis Apr 17 '13 at 12:02
  • 2
    Here is a link where Martin Fowler discusses the Richardson Maturity model and summarizes it quite well: http://martinfowler.com/articles/richardsonMaturityModel.html – bh5k Apr 19 '13 at 13:23
  • 4
    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_. – Toddius Zho May 07 '13 at 15:08
  • 1
    PUT and POST can _BOTH_ be used for Create and Update. I cover this here: http://www.youtube.com/watch?v=hdSrT4yjS1g&t=18m12s I also cover idempotency mandates. I hope this is helpful! – Les Hazlewood Jul 18 '13 at 22:54
  • 1
    Using POST for an update allows the caller to provide a partial list of properties, being one the ones they want to update. – Lawrence Dol Nov 08 '13 at 03:07
  • 2
    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. – Trevor Jan 07 '14 at 22:45
  • 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)? –  Mar 15 '14 at 16:03
  • dalu check out http://stackoverflow.com/questions/6190323/rest-api-question-on-how-to-handle-collections-as-effective-as-possible-while-st for an answer to your question. – Paul Morgan Mar 16 '14 at 03:31
  • What about the other methods like PATCH and HEAD? Aren't they a part of REST? – Sebastian Barth Aug 08 '14 at 11:37
  • @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. – cowlinator Aug 10 '18 at 20:22
52

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

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • 1
    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. – zerobandwidth Aug 17 '15 at 18:55
  • 2
    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. – Martin Spamer Feb 02 '16 at 16:54
41

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.
ex0b1t
  • 1,292
  • 1
  • 17
  • 25
12

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

d1jhoni1b
  • 7,497
  • 1
  • 51
  • 37
9

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.

pleshy
  • 1,468
  • 2
  • 16
  • 22
7

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

Stuck
  • 11,225
  • 11
  • 59
  • 104
4

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:

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,

Bruno
  • 119,590
  • 31
  • 270
  • 376
3

Generally speaking, this is the pattern I use:

  • HTTP GET - SELECT/Request
  • HTTP PUT - UPDATE
  • HTTP POST - INSERT/Create
  • HTTP DELETE - DELETE
AJ.
  • 27,586
  • 18
  • 84
  • 94
  • 5
    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. – Donal Fellows Jun 01 '11 at 15:10
  • 1
    +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. – stand Jun 01 '11 at 16:02
  • 4
    *PUT and POST don't match exactly to either Update or Create*. True but AJ described what pattern **he** uses. – Piotr Dobrogost Sep 28 '11 at 18:54
1

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.

Matt Gibson
  • 37,886
  • 9
  • 99
  • 128