PUT has a big advantage in that it is mandated to be idempotent - it is safe to be repeated if it fails for whatever reason.
Meanwhile, POST is generally not considered safe to repeat in case of failure, because the client/proxy does not know where exactly the failure happened and if thus the processing has been already done or not.
Yes, that's why you use POST for everything with effects.
But if this is really your concern, you should also be using PUT to create new database records. In principle, those requests are safer to repeat than updates are, since the database will ignore repeated inserts and apply repeated updates. (Though as far as I can tell this only matters if your update adjusts a value rather than setting it outright.)
> Yes, that's why you use POST for everything with effects.
I don't get it. Isn't an idempotent effect still an effect?
> you should also be using PUT to create new database records.
If the client is free to define the identity, then I do. But if the resource gets e.g. an ID from Postgres sequence, then I need to use POST, because repeated call would create duplicates.
Meanwhile, POST is generally not considered safe to repeat in case of failure, because the client/proxy does not know where exactly the failure happened and if thus the processing has been already done or not.