> HTTP 200 OK
> look inside
> actually 401 Unauthorized wrapped in JSON for some reason
@malwareminigun @whitequark It's bad when API endpoints for state government services behave like that. More fun is 200 is successful but any and all errors or warnings return as 500 errors. 🥴
Oh, hey. It's GraphQL.

@tedward On one hand, GraphQL specification tried to be transport-neutral, so it doesn't specify what HTTP responses should people use when using GraphQL over HTTP. Also, since it allows multiple requests at once, how should it behave if just one request fail?

On the other hand, they should have standardized it. Like, I had issues with AniList's API due to that, if I try to optimize requests by using multiple requests (like fetching user data and show data at the same time) and one fails (like if the show or user doesn't exist), the entire request fails (in their implementation).

@qgustavor FWIW I’ve had this happen before, and it was because the API in question defined the return type as non-nullable. To support partial responses, return types must be nullable so that GQL can insert a null where the data would go, and then put a corresponding error for that null in the errors array.

A GQL implementation might rightly be unable to give you a schema-compliant partial response to your query in that case, so it has to fail the whole response.

@NfNitLoop Hey, I asked help from people from AniList on GitHub almost six years ago! https://web.archive.org/web/20200919063914/https://github.com/AniList/ApiV2-GraphQL-Docs/issues/52

Thank you for this answer!

That being said, I don't think that's the answer to this issue, unless I misread documentation on nullable fields.

All queries fail when one fails · Issue #52 · AniList/ApiV2-GraphQL-Docs

It's similar to this issue: when doing multiple queries and some fails it returns 404 and null on all fields. As an example here's a simplified GraphQL query, the variables and the returned...

GitHub
@qgustavor ah, yep, that sounds like a bug in that implementation!
@malwareminigun @whitequark I do a lot of work with load balancers, this made me unreasonably angry.

Since this is blowing up: If anyone knows the original author of this I'd love to make sure they're credited somehow. I spent maybe 20 minutes trying to find the original before posting but gave up after finding nothing but a million reposts.

Of course I didn't exactly help the situation but enough people here seem to be happy about it that they're one of today's lucky 10000

@malwareminigun
The original original is probably this one, but I don't know who did the HTTP 200 variant first, sorry :(
https://pbfcomics.com/comics/quiz-kid/
Quiz Kid

The Perry Bible Fellowship

The Perry Bible Fellowship
@malwareminigun @whitequark I still can't believe HTTP has dedicated, usually unambiguous status codes indicating failure states and actual websites don't even use them properly

@iagondiscord I mean... given that there was a whole 'hey maybe we should actually use what's in the HTTP protocol" that got a while name / movement 'REST' I guess we shouldn't be that surprised.

At the end of the day it didn't matter what the details of the HTTP protocol were. What matters is that it's the protocol browser speak, and the same content page served with a 2XX code vs. a 4XX code is not a meaningful user facing difference.