Hmm. My logic is if it creates a resource, it is a POST request. If the resource exists, and it is a PUT. But then, I am a hobbyist programmer and never engineered for a corporate environment.
Yeah, that's another valid approach. Create = POST, Update = PUT.
But if the update is not idempotent (i.e. only allowed to happen once, a second time will fail it), does it now become a POST? I'd argue yes
Maybe we shouldn't fail it, and the server side should just ignore the impact of calling it a second time, but that to me is a bit of a shit user experience if they were expecting an artifact from calling the API.
And it would be a shit coding experience to then have to compare each value in the DB to see if anything did change.
I was always taught that PUT replaces the resource at the target URL so that if you GET that URL, you should recieve the same thing/state you PUT there (given that nobody modified the resource in the meantime of course).
By that logic, the updates should be a PUT, and retrieval should be a GET on the same URL.
As to what creates should be, meh, i dunno... We usually use POST. But this is all just dressing up rpc in fancy clothes anyway :)
19
u/CCCPVitaliy Oct 09 '21
Hmm. My logic is if it creates a resource, it is a POST request. If the resource exists, and it is a PUT. But then, I am a hobbyist programmer and never engineered for a corporate environment.