3 ms·

That leads to cleaner code for the frontend frameworks, better interoperability and simpler debugging. Web server error codes are for web server failures and ap

by jack9 9y ago

That leads to cleaner code for the frontend frameworks, better interoperability and simpler debugging. Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I run in to this all the time and once we adopted it (for all our APIs), life has been better for customers and our internal teams.

strictnein 9y ago
> "application level errors are communicated via a 200, properly" Wiki: 2xx Success This class of status codes indicates the action requested by the client was received, understood, accepted, and processed successfully RFC 2616: 10.2.1 200 OK The request has succeeded Not really "proper" to use it that way, but if it works for you and your users I guess go for it. Also, I highly disagree with the rest of it (cleaner code, better interoperability, simpler debugging), but those are matters of opinion so there's no point in arguing them.
- jack9 9y ago
  > client was received, understood, accepted, and processed successfully How is this not processed successfully? The request was processed successfully by the webserver ... and the error was handled by the application, so you can reliably say it was processed successfully at that level, down to the CPU. Narrow interpretation to fit a narrative has no technical merit. That being said, standards are set with certain models in mind and are imperfect almost uniformly, so I don't put too much stock in adherence to what someone imagined or put through committee at some point. I do try to find the best way to iterate reliably with least astonishing abstractions and predictable interfaces. I reason about it in the terms of the standard and it serves my teams.
VonGallifrey 9y ago
> Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I guess google, facebook, microsoft and all the others are doing it wrong then? Or Improperly according to you? Because they do not respond with a 200 on application level errors in their APIs.
- haburka 9y ago
  The needs and use case for Google, Microsoft, and Facebook are radically different than anyone else. No developer should imitate them blindly because, chances are, the conditions you are working in do not match the big four. There is no ideal way of coding, instead, you match your style to what is needed. I wish more people understood that.
  - icebraining 9y ago
    It's an error code, not a massively distributed system. There's no reason why the solution for the "big four" should be different than for anyone else. Especially since their APIs are designed to be used by everyone else.
- jack9 9y ago
  > I guess They made a choice to treat multiple applications as one. That's not what I would prefer and is less useful in my opinion. There are some CDNs and payment processors that are in operation, that use the 200 error response, so I tried it. I think it's clearly superior. YMMV
dragonwriter 9y ago
> Web server error codes are for web server failures and application level errors are communicated via a 200, properly. No, expressly in the HTTP spec, 5xx error codes are server errors. 4xx codes are all different kinds of application-level (usually resource-specific) errors. 2xx codes are full-stack success codes.

by jack9 9y ago

strictnein 9y ago

> "application level errors are communicated via a 200, properly" Wiki: 2xx Success This class of status codes indicates the action requested by the client was received, understood, accepted, and processed successfully RFC 2616: 10.2.1 200 OK The request has succeeded Not really "proper" to use it that way, but if it works for you and your users I guess go for it. Also, I highly disagree with the rest of it (cleaner code, better interoperability, simpler debugging), but those are matters of opinion so there's no point in arguing them.

jack9 9y ago
> client was received, understood, accepted, and processed successfully How is this not processed successfully? The request was processed successfully by the webserver ... and the error was handled by the application, so you can reliably say it was processed successfully at that level, down to the CPU. Narrow interpretation to fit a narrative has no technical merit. That being said, standards are set with certain models in mind and are imperfect almost uniformly, so I don't put too much stock in adherence to what someone imagined or put through committee at some point. I do try to find the best way to iterate reliably with least astonishing abstractions and predictable interfaces. I reason about it in the terms of the standard and it serves my teams.

VonGallifrey 9y ago

> Web server error codes are for web server failures and application level errors are communicated via a 200, properly. I guess google, facebook, microsoft and all the others are doing it wrong then? Or Improperly according to you? Because they do not respond with a 200 on application level errors in their APIs.

haburka 9y ago
The needs and use case for Google, Microsoft, and Facebook are radically different than anyone else. No developer should imitate them blindly because, chances are, the conditions you are working in do not match the big four. There is no ideal way of coding, instead, you match your style to what is needed. I wish more people understood that.
- icebraining 9y ago
  It's an error code, not a massively distributed system. There's no reason why the solution for the "big four" should be different than for anyone else. Especially since their APIs are designed to be used by everyone else.
jack9 9y ago
> I guess They made a choice to treat multiple applications as one. That's not what I would prefer and is less useful in my opinion. There are some CDNs and payment processors that are in operation, that use the 200 error response, so I tried it. I think it's clearly superior. YMMV

dragonwriter 9y ago

> Web server error codes are for web server failures and application level errors are communicated via a 200, properly. No, expressly in the HTTP spec, 5xx error codes are server errors. 4xx codes are all different kinds of application-level (usually resource-specific) errors. 2xx codes are full-stack success codes.