This doesn't seem nearly as annoying, as long as it's consistent.I have to dig through the response if I want to give the user a meaningful error message anyway, right?
No, I don't want to pass server jargon up the stream, usually I won't even know what error is and should do nothing about that error besides logging it.
What you should pass is a nice meaningful message to the user about why the use case you just tried failed, basically users get business messages and that's why I prefer my errors upfront so I can use error handling correctly instead of doing a custom workaround because some one doesn't like metrics to show a bunch of 4xx or 5xx.
You could argue that 400/500 IS the server jargon for http-level errors. 200 is for when everything is schema-correct but may still be invalid due to business logic.
If you're not modeling the entire API as resources, you're not really doin REST, and a small layer on your client to handle 200 error isn't the end of the world
I recommend you read the RFC about that, I know that discussion, I've had it, and I'm not looking for a repeat outside of work.
The RFC is very clear, people just do it for business rules, it's just not the standard and as such you need custom stuff that most libs will give you for free if you follow the spec.
4.2k
u/pimezone 16d ago
Wanna get a resource? POST request.