GraphQL returnerer alltid HTTP 200 for en vellykket transport; problemer rapporteres i svarets body, ikke i statuskoden. Et svar har to nøkler på toppnivå: data og errors, og begge kan være til stede samtidig — det er delvise data.
Hvis resolveren til ett felt kaster, blir det feltet , en oppføring legges til i , men alle andre felt resolves fortsatt. Klienten får det som lyktes pluss en beskrivelse av det som feilet.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // nøyaktig hvilket felt som feilet
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Feltet extensions.code bærer en maskinlesbar feilkode så klienter kan forgrene seg på den. Om et felt som kaster bare nuller seg selv eller bobler oppover avhenger av nullability: et non-null felt (posts: [Post!]!) som feiler nuller i stedet sin nærmeste nullable parent.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// legg ved en stabil kode klienter kan switche på; skjul interne detaljer
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Mange team modellerer også forventede feil (validering, "e-post allerede i bruk") som del av schemaet via union-/result-typer, og reserverer errors-arrayen for uventede feil — for å holde typingen på lykkelig-sti ren.
Intervjuere undersøker om du vet at feil bor i body sammen med delvise data, at koder hører hjemme i extensions, og at nullability styrer hvor langt en feil bobler. Å forveksle GraphQL-feil med HTTP-statuskoder er et klassisk tegn på at noen bare har brukt REST.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner