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.
It's the same sort of pedantry as correcting someone's use of their/there/they're. Yes, technically you're correct in what you're talking about, but arguing minutiae that is probably not relevant to the overall discussion.
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."
even if you return 202 + pending, you still have the same issue underneath the outcome depends on work that happens outside the request
queues, retries, third party stuff, timing between systems
you can model it nicer in the api, but you still don’t really control when or if things actually finish the way you expect
that’s been the tricky part for me in production not the status code, but the gap between “request handled” and “did the thing actually happen”
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.