Should HTTP POST not be recommended?

Quoting from CouchDB Documentation :

It is recommended that you avoid POST whenever possible because proxies and other network intermediaries will sometimes re-send POST requests, which can lead to duplicate documents.

As far as I understand, this shouldn't happen at the protocol level (confused user armed with a double click is a completely different story). What's the best course of action?

Should we really try to avoid POST requests and replace them with PUT? I don't like this as they convey a different meaning.

Should we anticipate this and protect requests by unique identifiers where we want to avoid accidental duplication? I don't like this either: it complicates the code and prevents situations where multiple identical messages may be required.

+2


a source to share


3 answers


Should we really try to avoid POST requests and replace them with PUT? I don't like it when they convey different meanings.



For document creation (as mentioned in the document you are citing) this is exactly the correct meaning. For document modification, irregular requests are not a problem.

+2


a source


We should avoid POST requests when the request is idempotent and changes the state of the server (it shouldn't change the state of the server every time it is executed, when creating a document this means the document has to be created once).

POST is fine if the request is non-idempotent . This means that every time a request is sent, there is a server state change. It doesn't matter for update or deletion.



Of course, due to web browser support, only GET and POST requests were really accepted, because POST does everything that PUT does (it's just not designed for idempotent requests).

+2


a source


I must have been very lucky in my WebMaster days to never see duplicate POST requests.

TCP / IP is sending numbered messages, I don't know why any webserver will not discard duplicates.

Is this repetitive POST thing really a problem?

0


a source







All Articles