Not a great read. Its a very generic article that doesn't actually give you any information. Its too high level for anyone that actually works in this field and for anyone not in this field they are better off with an introduction to the topics of status codes and http layer works.
> A 200 OK response tells you the request was accepted. It tells you nothing about what actually happened after.
???
From [0]:
> The HTTP 200 OK successful response status code indicates that a request has succeeded.
From [1]:
> The HTTP 202 Accepted successful response status code indicates that a request has been accepted for processing, but processing has not been completed or may not have started.
Users expect that their ticket been successfully purchased when the gray "Buy" button turned "Green! Yay", this is "the system" or whatever they call it. Just because the request went to backend and returned 200 OK doesn't necessarily mean that everything after that successfully completed, maybe the payment webhook was badly configured, and so on.
It seems pretty clear to me that this is what the author means and are talking about. But I'm not entirely why they're talking about this, or if there is any further point beyond just the "technically correct but ultimately not important" part.
Current GraphQL-over-HTTP recommends using 200 OK when returning non-successful properly defined reponses:
- §6.4.1 (application/json): "The server SHOULD use the 200 status code for every response to a well-formed GraphQL-over-HTTP request, independent of any GraphQL request error or GraphQL field error raised."
200 is correct at the protocol level, no argument there.
I think where it gets confusing is that people treat it as “done”, while in a lot of real systems it just means the request got accepted and handed off.
after that it’s queues, providers, retries, all kinds of stuff you don’t really see.
so you end up with “success” at the API layer but still inconsistent outcomes.
that’s mostly what I’ve been running into in production.
9 comments
> A 200 OK response tells you the request was accepted. It tells you nothing about what actually happened after.
???
From [0]:
> The HTTP 200 OK successful response status code indicates that a request has succeeded.
From [1]:
> The HTTP 202 Accepted successful response status code indicates that a request has been accepted for processing, but processing has not been completed or may not have started.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
Users expect that their ticket been successfully purchased when the gray "Buy" button turned "Green! Yay", this is "the system" or whatever they call it. Just because the request went to backend and returned 200 OK doesn't necessarily mean that everything after that successfully completed, maybe the payment webhook was badly configured, and so on.
It seems pretty clear to me that this is what the author means and are talking about. But I'm not entirely why they're talking about this, or if there is any further point beyond just the "technically correct but ultimately not important" part.
- §6.4.1 (application/json): "The server SHOULD use the 200 status code for every response to a well-formed GraphQL-over-HTTP request, independent of any GraphQL request error or GraphQL field error raised."
200 is correct at the protocol level, no argument there.
I think where it gets confusing is that people treat it as “done”, while in a lot of real systems it just means the request got accepted and handed off.
after that it’s queues, providers, retries, all kinds of stuff you don’t really see.
so you end up with “success” at the API layer but still inconsistent outcomes.
that’s mostly what I’ve been running into in production.
curious how others think about that.
This format of writing.
Partial sentences.
LinkedIn haiku.