5 ms·

I'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 res

I'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 ago
Whether 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 ago
  that'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 ago
While 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 ago
  Two 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 ago
    With 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
      If under your suggestion you have to look at the details of a 404 anyway to get a detailed error message, what is the point of the 404? Your client always has to do an explicit check for error/no-error. Why make them check two different locations? Just always look at the body: one location.
      - lazyasciiart 7y ago
        You don't have to. Plenty of times, a 404 is all I need to know. Why make the client check two different locations?
        celticmusic 7y ago
        Because they can pull extra information out that can help them understand why they're receiving a 404. The lack of information can itself become a signal.
        yardstick 7y ago

zonidjan 7y ago

Whether 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 ago
that'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 ago

While 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 ago
Two 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 ago
  With 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
    If under your suggestion you have to look at the details of a 404 anyway to get a detailed error message, what is the point of the 404? Your client always has to do an explicit check for error/no-error. Why make them check two different locations? Just always look at the body: one location.
    - lazyasciiart 7y ago
      You don't have to. Plenty of times, a 404 is all I need to know. Why make the client check two different locations?
      - celticmusic 7y ago
        Because they can pull extra information out that can help them understand why they're receiving a 404. The lack of information can itself become a signal.
      - yardstick 7y ago