1

I understand what an idempotent operation is and what a safe operation is from HTTP point of view.

Recently, a colleague changed an update operation from PUT to POST claiming it's a matter of style.

I would like to get all my arguments ready before discussing this.

Does a user agent, proxy, or any other component in the internet take advantage of PUT being idempotent?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Moha the almighty camel
  • 4,327
  • 4
  • 30
  • 53
  • There are so many HTTP-APIs out there in the wild violating those REST guidelines (idempotent POST, non-idempotent PUT, DELETE with request body, etc.), that I doubt any component can afford to rely on these properties. That doesn't mean that you should do it as a good net citizen, but it means that the risk of breaking something is reasonably small. – Heinzi Jun 26 '21 at 06:23
  • Does this answer your question? [What is the difference between POST and PUT in HTTP?](https://stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http) – Tom W Jun 26 '21 at 07:00

1 Answers1

2

What do I risk if I use a POST for idempotent operation?

You do not risk anything.

Idempotency means that an operation needs to be repeatable. There is no technical reason that POST with is intended for operations that are not constrained to be repeatable would break in any way if the operation did actually turn out to be repeatable.

Does a user agent, proxy, or any other component in the internet take advantage of PUT being idempotent?

Not really. You could (in theory) write a user agent to automatically retry a failed PUT, on the assumption that the server implements its PUT API methods to have idempotent behavior. Unfortunately, that is not guaranteed, so it would be unwise for a generic user agent to assume that.

Recently, a colleague changed an update operation from PUT to POST claiming it's a matter of style.

If your colleague did that because the operation is non-idempotent in a significant way, then they are correct. It is a matter of style. But style matters when you are designing an API for others to use. (They are likely to expect PUT operations to be idempotent ... and be unpleasantly surprised if they aren't.)

If the change was done for another reason, then you (or they) should clarify what was meant by "it is a matter of style". It is not necessarily correct or incorrect to change an (idempotent) PUT to an (idempotent) POST, but it the stylistic reasoning would be based on other things.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216