27

I am learning about REST and PUT/DELETE, I have read that both of those (along with GET) is idempotent meaning that multiple requests put the server into the same state.

Does a duplicate PUT/DELETE request ever leave the web browser (when using XMLHttpRequest)? In other words, will the server be updating the same database record for each PUT request, or will duplicate requests be ignored automatically?

If yes, how is using PUT or DELETE different from just using POST?

I read an article which suggested that RESTful web services were the way forward. Is there any particular reason why HTML5 forms do not support PUT/DELETE methods?

nbro
  • 15,395
  • 32
  • 113
  • 196
Lea Hayes
  • 62,536
  • 16
  • 62
  • 111
  • 5
    Nothing is automatic. They're only idempotent if the server receiving the requests is truly RESTful and implements them in an idempotent manner. I'm not writing this as an answer because it's off-topic for StackOverflow. Ask at http://programmers.stackexchange.com if you must ask. – Dan Grossman Aug 10 '11 at 19:54
  • 1
    you may also want to check out the following answers: http://stackoverflow.com/questions/4088350/is-rest-delete-really-idempotent http://stackoverflow.com/questions/630453/put-vs-post-in-rest – Deep Kapadia Aug 10 '11 at 19:58

4 Answers4

55

REST is just a design structure for data access and manipulation. There's no set-in-stone rules for how a server must react to data requests.

That being said, typically a REST request of PUT or DELETE would be as follows:

DELETE /item/10293

or

PUT /item/23848
foo=bar
fizz=buzz
herp=derp

The requests given are associated with a specific ID. Because of this, telling the server to delete the same ID 15 times will end up with pretty much the same result as calling it once, unless there's some sort of re-numbering going on.

With the PUT request, telling the server to update a specific item to specific values will also lead to the same result.

A case where a command would be non-idempotent would typically involve some sort of relative value:

DELETE /item/last

Calling that 15 times would likely remove 15 items, rather than the same last item. An alternative using HTTP properly might look like:

POST /item/last?action=delete

Again, REST isn't an official spec, it's just a structure with some common qualities. There are many ways to implement a RESTful structure.

As for HTML5 forms supporting PUT & DELETE, it's really up to the browsers to start supporting different methods rather than the spec itself. If all the browsers started implementing different methods for form submission, I'm sure they'd be added to the spec.

With the web going the way it is, a good RESTful implementation is liable to also incorporate some form of AJAX anyway, so to me it seems largely unnecessary.

Cory House
  • 14,235
  • 13
  • 70
  • 87
zzzzBov
  • 174,988
  • 54
  • 320
  • 367
  • 2
    REST isn't an official spec but it's just reminding us not to deviate from HTTP with new methods or adding state to transactions. Therefore, a request like `DELETE /item/last` is not idempotent so it shouldn't be used. For example, a browser would send a request again without asking for confirmation from the user when hitting back. Also, `POST /item/last?action=delete` seems like a bad idea, how can you guarantee that you're deleting the resource you intend to? – Ruan Mendes Apr 12 '13 at 18:34
  • @JuanMendes, good point. I actually cover this issue at the end of [my answer to a different question](http://stackoverflow.com/questions/4573305/rest-api-why-use-put-delete-post-get/4573426#4573426), and I should probably touch up this answer to reflect a better approach. – zzzzBov Apr 12 '13 at 18:38
  • According to [RFC2616](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) methods GET, HEAD, PUT and DELETE are idempotent. So you are not allowed to use DELETE /item/last just like you are not allowed to use GET /item/last or PUT /item/last. The reason is that intermediate servers should be able to repeat DELETE request in case of failure or no response without breaking application logic. – alpav Sep 02 '15 at 19:41
  • 2
    "So you are not allowed..." it's programming, you're **allowed** to do whatever you'd like because no one can stop you. That's not to say that the concept of `/item/last` is a good one, but the question was about whether this behavior was automatic, which it most decidedly isn't. – zzzzBov Sep 02 '15 at 23:51
  • This answer is very helpful. I was very confused by the definition of PUT method because I couldn't understand what rules r given to PUT method by HTTP that ensures its idempotency. Now I knew that nothing is idempotent, it's upto the programmer that he should write the invoked method at controller in a way that ensures the idempotency. – Arun Raaj Sep 17 '19 at 21:58
  • One question. What about PUT requests without ID specified? It will work like POST, it will create a new object each time you call this endpoint, right? I know it depends on how it is implemented on a server, but I'm asking how should it be implemented. – Piotr Filochowski Jun 30 '21 at 16:22
7

Does a duplicate PUT/DELETE request ever leave the web browser (when using XMLHttpRequest)?

Yeah, sure. Idempotence is only a convention and it's not enforced. If you make a request, duplicate or not, it will run through.

In other words, will the server be updating the same database record for each PUT request, or will duplicate requests be ignored automatically?

If it conforms to REST it should update the same database record twice, for example running UPDATE user SET name = 'John' twice. There is not guarantee what it will or will not do though, it depends on how it's implemented.

If yes, how is using PUT or DELETE different from just using POST?

It's just a convention. PUT and DELETE requests may or may not be handled differently from POST in the site's code.

I read an article which suggested that RESTful web services were the way forward. Is there any particular reason why HTML5 forms do not support PUT/DELETE methods?

I'm not really sure, to be honest. You can work around this by using a hidden <input> field called _method or similar and set it to DELETE or PUT, and then handle that server side.

Andreas Bonini
  • 44,018
  • 30
  • 122
  • 156
  • 1
    XMLHttpRequest would still support PUT/DELETE even if the HTML 5 spec does not. right? That would be another solution. I guess that would be how seriously do the browsers take to the spec as well. – Deep Kapadia Aug 10 '11 at 20:04
  • @Deep: yes, but technically speaking it has nothing to do with HTML forms which is what he asked :S – Andreas Bonini Aug 10 '11 at 20:18
  • 4
    Idempotence is more than a convention - it is a promise that the server makes to the client (and intermediaries). However, as the implementer of the service, it is your responsibility to fulfill (or break) that promise. It is not enforced as such, but rather, intermediaries (i.e. proxies) make assumptions based on that promise and if it is not true, it may have bad consequences for your service or your clients. The only difference from POST is that POST makes NO promises about safety or idempotence, so proxies make no assumptions about it. – jhericks Aug 12 '11 at 15:52
  • Re: "Does a duplicate PUT/DELETE request ever leave the web browser" - they should not be issued by web browser itself more than once. If TCP stack returns error to the browser, it should report to JavaScript code and the code needs to try to send it again, which is safe to do as per spec. – alpav Sep 02 '15 at 19:57
2

PUT operation are idempotent but not safe operation. On success if PUT operation is repeated it will not insert duplicate records. Repeat PUT operation in case of NetworkFailure errors after verifying conditional headers like If-unmodified-since and/or if-match. Don't repeat in case of 4XX or 5XX error codes.

Yamunarv
  • 21
  • 1
0

REST aims to establish a syntax convention regarding the HTTP method to use; each back end is free to implement anything they want, devs could break the convention but will cause unnecessary confusion if used by others not involved in the development.

For DELETE, if you delete some item with an ID, the server should responded it's deleted; if delete again, it's no more there so server responded "already removed", also good because your purpose is fulfilled. Same for PUT, because you provide the new status of your resource, the status yet-to-be; if it's already updated, mission complete and it's the same for the client.

WesternGun
  • 11,303
  • 6
  • 88
  • 157