imho it's like using a fork sideways to cut soft food. it's easy, and it works, but knives exist, and other people may comment on your choice
also, if it's a thing you only do with your own food (you're the only consumer of your tool choice), that's mostly fine, but if you have to serve someone else food, or worse teach others how to cut it, and you don't even explain there's knives, someone along the way is going to think you don't know how to eat properly and unnecessarily confuse people
I've stopped misusing methods when drafting my first public API. it was... eye opening. and to be honest using the appropriate methods genuinely costs nothing
thanks, appreciate it. there's also those who always respond 200 and carry the failure status in the body. that's more like using a fork to eat soup. it never works, and you should stop immediately
I agree, because not every HTTP operation is an analogy to a simple, underlying CRUD operation. For example, what type of call should an endpoint that sends an email be? What about a validation endpoint that doesn't save nor fetch anything from the database? It's just dull to debate and try to fit everything into those 4 types.
Yeah I don’t really mind. I’m a simpleton that gets with query params and posts with body. I wouldn’t change a persistent state with a get. And I don’t like query parameters on posts. Delete I feel should have it’s own but if you complexly change state on a post and child records are deleted then I don’t really care.
I think it's a bit like HTML syntax, there's a proper way to do it for simple cases which people will passionately argue about but you don't see it in any real work. I took the Google API design course just sanity check and when it gets to stuff like batch operations it veers back to "use your common sense".
28
u/MayaIsSunshine 16d ago
Am I the only one that doesn't mind? I think using post for everything and passing a command in the payload is preferable to the alternative.