4 ms·
> 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 co
by 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 agoThat 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 agoYes. 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"