GraphQL returnerer altid HTTP 200 for en vellykket transport; problemer rapporteres i svarets body, ikke i statuskoden. Et svar har to top-level-nøgler: data og errors, og begge kan være til stede på samme tid — det er partielle data.
Hvis ét felts resolver kaster en fejl, bliver det felt , en post tilføjes til , men alle andre felter resolves stadig. Klienten får det, der lykkedes, plus en beskrivelse af det, der fejlede.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Feltet extensions.code bærer en maskinlæsbar fejlkode, så klienter kan forgrene sig på den. Om et fejlende felt kun sætter sig selv til null eller bobler opad afhænger af nullability: et non-null-felt (posts: [Post!]!), der fejler, sætter i stedet sin nærmeste nullable parent til null.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// attach a stable code clients can switch on; hide internal details
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Mange teams modellerer også forventede fejl (validering, "email optaget") som en del af skemaet via union/result-typer og reserverer errors-arrayet til uventede fejl — hvilket holder typerne på happy-path rene.
Interviewere undersøger, om du ved, at fejl lever i body'en sammen med partielle data, at koder hører hjemme i extensions, og at nullability styrer, hvor langt en fejl bobler. At forveksle GraphQL-fejl med HTTP-statuskoder er et klassisk tegn på, at nogen kun har brugt REST.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér