> Oh noooo, you have to.... handle errors coming out of API's you consume. What an imposition... It must be terrible to be you, always having to write code to handle when things don't go exactly down the happy path.
Do you really think this is a conversation about never wanting to handle errors, or is that sarcasm as a convenient way of getting out of actually thinking during the discussion?
Good specific HTTP status codes from the application layer help the client sort errors by type before they have to parse specifics. Or in cases where the client may not even have been prepared for the specifics.
Have you really never found a software situation where it's useful to know what the type of error is before you get into the details?
If that's the case, you definitely shouldn't be anywhere near API design.
> Imagine seeing a 500 and knowing for sure that there's a server misconfiguration.
Imagine knowing there's a whole range of 5xx status codes that allow for both that possibility and others.
> Being able to trust http status codes: it's what's for dinner.
Well, I'm glad we've gotten here, given that you seemed to start with "200 all the things, sort it out in the response body."
> Do you really think this is a conversation about never wanting to handle errors, or is that sarcasm as a convenient way of getting out of actually thinking during the discussion?
It was me making fun of someone trying to argue that you would have to write code for the non-happy path in scheme A, but not B.
> Good specific HTTP status codes from the application layer help the client sort errors by type before they have to parse specifics. Or in cases where the client may not even have been prepared for the specifics.
> Have you really never found a software situation where it's useful to know what the type of error is before you get into the details?
Yes, because you could never embed that sort of information into the JSON, that's not what it's for! It's for... well I guess if you're not using it for that sort of information I don't know what it's for.
> Imagine knowing there's a whole range of 5xx status codes that allow for both that possibility and others.
11 5xx status codes. I'm glad to know these cover all possibilities for the software you write, but you know what's even worse than anything we've discussed here?
15 different API's defining 512 to mean different things specific to their software. All in the name of software cleanliness, because parsing json is apparently icky and hard in brainfuck, their API language of choice I guess?
> because parsing json is apparently icky and hard in brainfuck, their API language of choice I guess?
It's quite clear that what I'm talking about here has nothing to do with the ease of having a piece of software parse JSON, but with the difficulties introduced by thumbing your nose at helpful conventions in a context where "rough consensus and running code" has been brilliant at enabling a spectacular network of interconnected clients and servers.
It's less clear why you'd insist on returning to characterizing these points as "oh, you think JSON parsing is hard", but some of what it could indicate isn't flattering. Whether you're content with that or rueful about it at some point might also say something, though with any luck I will no longer be among those evaluating it.
> 11 5xx status codes. I'm glad to know these cover all possibilities for the software you write
Not my claim. My claim is that existing status codes cover some broad categories, and by recognizing what your status conditions have in common with existing HTTP codes, you can do early sorting across condition categories, and work in cooperation/re-use with other pieces of code and infrastructure.
> but you know what's even worse than anything we've discussed here? 15 different API's defining 512 to mean different things specific to their software.
Which of course applies equally to your individualized in-band error codes... that sword you were swinging cuts both ways, right? Except, of course, that they're not really exactly equal situations: if you 200-plus-response-body all the things, a client developer has to learn not only what your custom error codes mean without the benefit of working from HTTP-related conventions/groupings that you apparently won't engage, but they have to figure out which property/s they're passed back under when there's already a perfectly good standard for these things in the header information.
Contrast that with the situation of a developer who is working on a client that gets a status code header 512 back from an API written by someone who groks and tries to work with status code groupings. Even if the client dev has no idea what the server means by 512 specifically, they already know that it's not related to a user input or even a client request problem, and more importantly, code already written to deal with other 5xx errors either for this client or other clients knows at least that much too. If it turns out general 5xx handlers aren't adequate, they can turn to docs and/or response body info to learn more about 512 condition specifics and augment the general case with specific handlers (however rare the case may be in which a client might need to do anything other than relay API status messages).
> Yes, because you could never embed that sort of information into the JSON, that's not what it's for
You certainly could. You could also put all the other header information into the response body, too... Content-Type, Cookie info, Authorization headers, CORS, etc. For some reason people don't. Hell, I'll bet even you don't. Perhaps you'll ask yourself why. Perhaps not.
> It was me making fun of someone trying to argue that you would have to write code for the non-happy path in scheme A, but not B.
This isn't even an accurate summary of your comment, let alone an adequate characterization of or response to mine.
Good luck with your own happier paths. If you're as much more correct than I am about this topic as your rhetoric (if not your logic) seems to imply you believe you are, then I'm sure your decisions will be their own reward.
Do you really think this is a conversation about never wanting to handle errors, or is that sarcasm as a convenient way of getting out of actually thinking during the discussion?
Good specific HTTP status codes from the application layer help the client sort errors by type before they have to parse specifics. Or in cases where the client may not even have been prepared for the specifics.
Have you really never found a software situation where it's useful to know what the type of error is before you get into the details?
If that's the case, you definitely shouldn't be anywhere near API design.
> Imagine seeing a 500 and knowing for sure that there's a server misconfiguration.
Imagine knowing there's a whole range of 5xx status codes that allow for both that possibility and others.
> Being able to trust http status codes: it's what's for dinner.
Well, I'm glad we've gotten here, given that you seemed to start with "200 all the things, sort it out in the response body."