8 ms·

True. 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 det

True. 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.

capableweb 5y ago
> My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. 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.
- hakre 5y ago
  That must be something fetch specific, per the HTTP specs IIRC, any status code should be passed to the application - and the way I read it - unfiltered. It is neither an error nor an exception, the request is successful. A DNS or server connection issue would not be. 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.
- beardedetim 5y ago
  Yes. Yes Yes yes. Status code is important beyond your eyes and your hand-rolled api interactions. I can't believe the people here saying "fuck it, I always return 200"
reidjs 5y ago
That part of GQL drives me nuts. How the heck do people do error handling on the frontend with API requests through GQL? Instead of `try catch`, do you do `if (response.error) {}`?
- samsonradu 5y ago
  Yes, can be handled with middleware (interceptors) that throw the `response.error`
beardedetim 5y ago
The fact that I have to parse the body and intropsect its payload to know that the query is malformed is the worst client experience ever.
- shroompasta 5y ago
  APIs should be giving back specified error messages regardless as 4xx and 5xx errors can still be too generic. 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.
  - beardedetim 5y ago
    I don't want to introspect response bodies when I can introspect the status. If I'm given 429, I can automatically do something based on that. If I need to introspect the response body I have to say "okay, look inside Joe's api and look for key Foo. But in Sally's api, look for key Bar. And in Mike's api look for key Baz. And...." 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.
    - shroompasta 5y ago
      I"m sorry, i'm not seeing the difference 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.

capableweb 5y ago

> My motivation came from GraphQL as it responds everything with 200s, and so far it has been humming along fine. 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.

hakre 5y ago
That must be something fetch specific, per the HTTP specs IIRC, any status code should be passed to the application - and the way I read it - unfiltered. It is neither an error nor an exception, the request is successful. A DNS or server connection issue would not be. 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.
beardedetim 5y ago
Yes. Yes Yes yes. Status code is important beyond your eyes and your hand-rolled api interactions. I can't believe the people here saying "fuck it, I always return 200"

reidjs 5y ago

That part of GQL drives me nuts. How the heck do people do error handling on the frontend with API requests through GQL? Instead of `try catch`, do you do `if (response.error) {}`?

samsonradu 5y ago
Yes, can be handled with middleware (interceptors) that throw the `response.error`

beardedetim 5y ago

The fact that I have to parse the body and intropsect its payload to know that the query is malformed is the worst client experience ever.

shroompasta 5y ago
APIs should be giving back specified error messages regardless as 4xx and 5xx errors can still be too generic. 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.
- beardedetim 5y ago
  I don't want to introspect response bodies when I can introspect the status. If I'm given 429, I can automatically do something based on that. If I need to introspect the response body I have to say "okay, look inside Joe's api and look for key Foo. But in Sally's api, look for key Bar. And in Mike's api look for key Baz. And...." 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.
  - shroompasta 5y ago
    I"m sorry, i'm not seeing the difference 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.