I have personally gone off the deep end and started writing 200, 400, and 500 for all my status codes instead of the specific 2xx, 4xx, 5xx ones.
If details of an error response need to be mentioned, it will be in the error response body.
My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine.
True REST are more guidelines if anything.
This is slightly annoying though, as other consumers (like `fetch` in JavaScript world for example) behaves differently if there is a error. If every status is 200, suddenly you need to manually check the response inside the returned promise, while if you answer with a correct status code when the server encountered an error (5xx), then it'll jump to the `.catch` part of the promise chain instead, which you're probably already handling anyways.
Similarly with curl if I'm not mistaken (don't have it in front of me). A 2xx would make the process return 0, while a 5xx would make it return non-0, so you can handle errors without having to read the actual response.
Similar with curl, 502 returns non-zero, 302 not. 4xx IIRC as well zero unless --fail is in use. The default makes it sensible/useful for smoke tests.
Perhaps GraphQL was aware of such client side "bugs" it choose to go "OK" first of all.
I can't believe the people here saying "fuck it, I always return 200"
For example, if you're rate limited (429), a robust API will still give you back data on how many requests you've made and how many requests you're allowed to make, so you're still going to have to check the payload regardless.
The combination of specific error status codes along with error messages has been redundant in my experience.
Furthermore, in Axios, checking for `error.response.data` isn't terribly far from `error.response.status`, so I'm unsure of this "worst client experience" you're talking about.
It's pretty intuitive for me.
I think its objectively worse that I, as the engineer, need to handle all of them differently when they all could have returned to me 429 instead and I could write a general wrapper for that.
how is
if error.response.status === 429 // then do something
different than
if error.response.data.err === 'RATE_LIMITED' // then do something
Also, do you mean to tell me that you've never had to elaborate on your error messages and just sent back status codes with no body?
I'm sorry but that does not sound like a robust API to me.
90% of my error responses have specified data, and I have to check the response body extremely often regardless of the status code being sent back.
If there's a way where we could say "this specific key will be this specific value in order to mean this specific scenario", I'd support that! But. Then. Isn't that the status that's I'm talking about?
I never said the error message can't or shouldn't be introspected and totally agree we should send our clients as much info as we can to make it clear on what they can do to fix any errors!
I just really really like being able to say "this specific field tells you, across all apis, what happened with this request" and don't see the gain in pushing that data into good luck finding out what key.
I'm currently dealing with an endpoint where it sends anywhere from 2-4mb worth of JSON data. Do I expect my clients to traverse every key and every deeply nested field to find what they're expecting for?
Absolutely not. because there's an internally standardized way of dealing with things and that is also precisely how we also deal with errors.
Now if you have an external API that faces many clients that you don't know about, then maybe there is consideration for usage of specific status codes.
But even then, your api should have documentation for it.
object graphs should be just called json or response body; you shouldn't use all these unorthodox terms.
a failure will be caught if a 400 was sent. This is how axios works - if you try a request, a 400 will automatically hit the catch.
a better designed system would be specificity. 75-90% of the time you're most likely going to look at the error body anyways.
I mean no personal offense but this is one of the most baffling and/or ignorant responses one could have imagined in this case.
json data => python server => redis
- json data gets serialized from json to string in the python server
- python server then stores that string in redis
to request from python server
- string is retrieved from redis server
- string is deserialized to send response as json
the Web client is in Javascript
JSON is native to Javascript
it is already readable to the client, there is no deserializing that needs to happen.
- It's non-standard, so different implementations will result in different formats
We have a standardized way of dealing with errors in which we will send 400/500
and have an error.data.err and an error.data.message in which err will give a title of the error, and the message elaborating the error in all of our errors across our APIs
the reason being is we don't need our developers to memorize dozens of generic status codes, and can be extremely specific in our error.data.err in which status codes can't.
It has worked for Facebook, It will work for us.