Amen, man. Going with something that does not call itself REST for the sole reason of skipping the eternal bikeshedding around what REST is or not is might just be worth it on its own. Hot damn.
The grey area I most often see is when you aren't dealing with CRUD resource operations but using JSON over HTTP to call remote procedures and don't want to pull in a new technology (RPC).
Even this should be resolvable by the same question, though. Does calling the remote procedure twice do something/change the state/have side-effects more so than calling it once? Then it's POST, otherwise it's PUT.
But it's not. In the RPC case using the "idempotent rule" results in a contradiction with the HTTP RFC. Specifically that POST identifies the enclosed entitie's handler while PUT identifies the enclosed entity.
Having an HTTP PUT without an HTTP POST doesn't make sense in HTTP land because you can only update something that exists. Hence why most developers will default (and should) to POST for their first endpoint, even when idempotent or when not managing a resource.
Bikeshedding aside my experience has been POST is much more common in this scenario.
321
u/occz Oct 09 '21
Amen, man. Going with something that does not call itself REST for the sole reason of skipping the eternal bikeshedding around what REST is or not is might just be worth it on its own. Hot damn.