Talk:Create, read, update and delete
|WikiProject Computing / Software||(Rated Stub-class)|
Note, I made the cleanup and NPOV-section edit, but I wasn't logged in. Insomniacity 23:23, 25 Jun 2005 (UTC)
New Jersey musician
Is there any truth in this odd section about a supposed NJ musician? Insomniacity 23:23, 25 Jun 2005 (UTC)
I am he. I added the entry myself; the neutrality issue notwithstanding, you may rest assured that this is not any type of slander of another person's character. -Crud.
While researching what this acronym means, I found a reference to a publication that said it stood for Create, and Read Until Deletion which is an algorithm for the management of memory shared by concurrent processes -- which which does not sound like "persistent storage" at all to me. Apparently it's in a paper by professors Wim H. Hesselink and Jan Friso Groote from the Eindhoven University of Technology in the Netherlands. A copy of the paper can be retrieved from here.
Unfortunately I don't feel qualified nor do I have the time to write about an article on the alternative meanin, but I think -- at a minimum -- it should be noted somewhere, perhaps on a disambiguation page (also something I don't know enough to create myself) (Martnym (talk) 20:12, 27 December 2008 (UTC))
Chalk River Unidentified Deposit
The page previously stated that the word CRUD originated from the acronym Chalk River Unidentified Deposit. In fact, this appears to be a backronym -- the dictionary etymology states that crud evolved from the middle english 'crudde'. RickScott 20:41, 13 July 2005 (UTC)
The current article has create map into the HTTP method POST and update map into the HTTP method PUT. I believe that create should map into PUT and update into POST. The reason is section 9.1.2 of RFC 2616. This section states that PUT has idempotence. In other words, when performing the same PUT request N times, the end result (resource) will be the same. POST does not have idempotence. Therefore, if you are updating with PUT, you are changing the resource and breaking idempotence. --IndyGreg 04:59, 7 September 2007 (UTC).
- I agree, either this mapping should be reversed or HTTP mapping removed at all. VadimIppolitov (talk) 11:51, 20 February 2012 (UTC)
- The whole PUT vs POST dilemma is a nonsense because:
- The standard hasn't been followed since decades, most webserver uses POST and GET and nothing more. So the use of PUT, DELETE and other are more "obsolete/archaic" features that very few system are using (excluding RESTful server).
- The use of GET to obtain and POST for send couldn't be followed for every case. For example, a hyperlink to send a GET that store information (insert) or a POST to send a big object that return (read) some information about this object (for example to send a list and return the average).
- So, the strategy to use GET or POST does not depend in the nature of the action (read, insert..) but in the nature of the website. And, for the same principle, PUT/DELETE could be (and usually is) replaced by standard GET and POST.
- --188.8.131.52 (talk) 00:48, 11 February 2013 (UTC)--184.108.40.206 (talk) 00:48, 11 February 2013 (UTC)
- The whole PUT vs POST dilemma is a nonsense because:
My reading of Section 9.1.2 is that a PUT can result either in a create or a replacement of a record (eg a delete followed by an insert). Also, a POST may result in a combination of any of insert, update and delete. The fundamental difference in the semantics between the HTML verbs and the database verbs is that a database verb expects the application to know the state of the database before applying the verb, whereas the HTTP verb does not. For exampe, PUT means that the server should create an object if it does not already exist, and to replace it if it already exists. This does not map to CRUD at all. LucQ 08:00, 18 October 2007 (UTC)
- I think this part should just be removed altogether; the behavior of HTTP methods is defined by the particular web application running on the server, not at all by the HTTP specification; so it makes for a very bad comparison to SQL which is strict and set in stone. -- intgr [talk] 01:19, 19 October 2007 (UTC)
One can use both PUT and POST to create OR update a ressource. Therefore a mapping to CRUD operations makes no sense for PUT and POST. The HTTP mapping should be removed at all. — Preceding unsigned comment added by 220.127.116.11 (talk) 15:04, 22 May 2012 (UTC)
I agree that the section should be removed. CRUD doesn't map as clearly/cleanly to HTTP "verbs" as it does to SQL. Furthermore, the heading of the section is "Database applications" -- HTTP is only tangentially related to this topic (if at all). — Preceding unsigned comment added by 18.104.22.168 (talk) 00:09, 29 May 2012 (UTC)
HTTP Mappings Resolution
I see that since this discussion was first started, not much has actually happened. Firstly, please let me clarify some details. Yes, you can create new resources on a server with BOTH PUT and POST, the difference though is that PUT can also specify the actual destination URI whilst with POST you leave it to the server to resolve. This effectively means that PUT is for replacing a resource with a completely new version, or as most people abuse it, to modify. I am glad to see that PATCH is acknowledged on this page, it is the method of choice when it comes to performing partial modifications on a resource. I think it's a fair point that most servers/clients fail to make use of the full range of HTTP methods properly, but that is mostly when it comes to actual websites, when we start talking about REST architectures it becomes a much more pertinent topic and as such I think this is a topic that should be covered hear, especially as this comparison is taught so frigging often, to pretend it doesn't exist is just insane. I will do my best to update the main article with this, along with try to explain about the limits of this comparison, please do respond if you feel strongly enough. Thecoshman (talk) — Preceding undated comment added 21:28, 20 May 2015 (UTC)
In the Dutch version of this page, the origin of CRUD is mentioned to be the book "Information Engineering" by James Martin, from the '70s. Which version should I believe? Tammojan (talk) 14:29, 30 September 2009 (UTC)