5 ms·
> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an
by celticmusic 7y ago
> When pointed out, the support answer was "we chose to give meaningful error messages instead of HTTP codes, that's why we respond with 200 in case there's an error in the request". Not the answer I was expecting.
I don't see the problem here. As a developer I'd much rather receive a standard json packet with information helping me figure out what went wrong.
I really don't understand your complaint here, I've designed and worked with both types of API's, and I find the standard json format to be far easier to deal with.
- wwweston 7y agoTotally agree that specific messaging is very convenient, but meaningful error messages and meaningful status codes aren't even remotely mutually exclusive. It's perfectly legitimate and even easy to send a 4xx or 5xx with a response body as JSON (or, for bonus points, with any other content type the client requests from possible server capabilities). And in my experience, having an out-of-body/band general indicator that doesn't require you to parse message responses makes things WAY easier. Well-designed APIs do both.
- celticmusic 7y agoI'm curious, what tech stack are you working in where parsing json is difficult? You want to talk about inconsistent? How about a 500 error may or may not result in the standard response format you're expecting because it may be coming from the server and it may be coming from the API. I'd much rather my 500 errors be legitimate server problems.
- zonidjan 7y agoWhether there's a bug in the underlying API code, or a bug in the web server, there's a risk that it "may or may not result in the standard response format you're expecting", and therefore... should be a 500 error. Yes, using the wrong status codes is a problem, you're right, that's the entire point of the thread you're responding to.
- celticmusic 7y agothat's flat out not true, it's a red herring. I can't think of very many tech stacks where an error inside the API couldn't be trapped and responded with a standard json response.
- wwweston 7y agoWhile we're asking questions: what stack out there makes reading/writing HTTP headers hard? Because that's all it takes to work with response codes. And yes, of course parsing JSON isn't difficult. Note that I said parsing messages -- the message field not the response body. And parsing that message field and checking conditionals to determine your client's behavior is something you'll have to write code for unless you're just relaying the error message back to the end user. Now, if you have an HTTP error code, you already know something about why the error condition is happening before you look at any part of an error message field. For example, if it's a 4xx error, and you know that your client generated the associated request to the API using user data, then you can probably just pass the error message straight back to the user w/o parsing it and going through your own error message logic (although that depends on the quality of the API too). > How about a 500 error may or may not result in the standard response format you're expecting Well, in that case, relying on some message field you might have supposed would be in a specific JSON response isn't going to help you much either. Might be better to have the HTTP error code and prepare your client to read responses based on multiple content types.
- yardstick 7y agoTwo reasons why using 200 instead of 404 can make sense: - No way to distinguish between the api client calling the wrong URL eg /mytypo/12345 instead of /myquery/12345. With 404, the client will not realise their mistake without debugging. - Lots of 404 errors can trigger security sensors. Having to whitelist 404 in a security sensor can be a pain to convince the team that manages them. Doubly so if they are part of the other company rather than yours. Aside from slightly less code to write, what benefit does 404 bring?
- lazyasciiart 7y agoWith a 200 your client won't know they've done anything wrong without debugging either. There is nothing preventing you from returning a detailed error message with your 404.
- yardstick 7y ago
- jayd16 7y ago>but meaningful error messages and meaningful status codes aren't even remotely mutually exclusive They actually are. Things besides your app code can response with 404 and 503 but not your error body. 4XX and 5XX bodies must be parsed more carefully and cannot be assumed to have a consistent structure with the same level of trust a 200 response would. Http codes are nice but it makes api error parsing much more complex so there are some trade offs.
- jventura 7y agoYou can return a 400 and still return a json payload in the http message body. Maybe is that what the parent is saying?
- james_s_tayler 7y agoMonitoring tools logging request/response payloads are just going to look at status codes. Breaking that kind of stuff cos you wanted to do it your way sucks.
- celticmusic 7y agoI guess I've never worked with a monitoring tool that didn't support deserializing json and looking for specific data.
- JackRabbitSlim 7y agoA huge and borderline criminal conflation with HTTP in general and REST-y APIs. The big fat elephant in all this is simple; None of our fucking opinions matter one god damn bit to the end client. Being originally designed to you know, consume hypertext over the hypertext transfer protocol, clients can and will do whatever the fuck they want with the status codes.
- wool_gather 7y agoWell, speaking as a client developer, the API is far, far easier for me to understand and write logic against if its authors agree to send back HTTP statuses with their standardized meanings instead of making up their own scheme.
- oftenwrong 7y agoHTTP statuses have no "standardized meanings" at the application level.