5 ms·
The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstanc
by einrealist 10y ago
The more important part is that HTML is for human interaction. So PUT or DELETE make no sense because the server should process user input under any circumstances and not take it as is.
- wvenable 10y agoWhy would the server process PUT or DELETE any differently from GET or POST. I already have single-page applications that do DELETE requests to delete items.
- einrealist 10y agoI do not know your applications. But PUT and DELETE are more like file operations and unless you do these things in your applications, POST is just fine. A PUT tells the server to make the payload available as is at the given URI. And if you do a GET on the URI, you should receive the exact payload that you put there. That may also include headers you send along with the PUT request (especially the Content-Type header). That's why a PUT is also able to invalidate a cache. So PUT and POST are very different. The problem with DELETE is this part of the specification: "The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully." That's why most applications are fine with using only GET and POST.
- rimantas 10y agoNever so that funny interpretation of REST(ish) architecture. That R in the name is a dead giveaway that you not necessarily will get exactly what you put there. I may put json and request xml, what are you gonna do, stab me?
- einrealist 10y agoWell, if the server understands the payload, it can return it in a different representation. There is nothing wrong with that. But a GET should always return the original payload when requested with the Accept header that matches the original Content-Type of the PUT request. edit: Better is to use a PUT for different representations: PUT /foo Content-Type: application/json {"foo":""} PUT /foo Content-Type: text/xml <foo></foo>
- wvenable 10y agoSeems to be no reason why GET should return the original payload. No client should even expect that as the resource could easily have been changed by another client in between requests.
- einrealist 10y agoObvious, but thats not the point.
- wvenable 10y agoWhat is the point? GET isn't even guaranteed to return the same payload every time, without PUT. Look at this website for example. The idea that you need to PUT something that be GET in exactly the same representation makes no sense given these basic facts.
- wvenable 10y ago"The client cannot be guaranteed that the operation has been carried out" You can add your own guarantees on top of this specification. So in my application, the DELETE is guaranteed to have succeed if you get a positive status code.
- ChemicalWarfare 10y agoDELETE is a bit of a can of worms - things like do you stick to response idempotency returning 200 even if the resource was already deleted or do you return a 404 on subsequent requests? That said though, IMO it's way more intuitive to use DELETE vs POSTing op=delete or even worse POSTing to a /resource/delete endpoint.