Is PUT/DELETE idempotent with REST automatic?

Question

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?

Answer 1

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.

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

Answer 3

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.