GraphQL restituisce sempre HTTP 200 per un trasporto andato a buon fine; i problemi vengono segnalati nel corpo della risposta, non nello status code. Una risposta ha due chiavi di primo livello: data e errors, ed entrambe possono essere presenti contemporaneamente — sono i dati parziali.
Se il resolver di un campo solleva un'eccezione, quel campo diventa null, viene aggiunta una voce in errors, ma tutti gli altri campi si risolvono comunque. Il client ottiene ciò che è riuscito, più una descrizione di ciò che è fallito.
{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Il campo extensions.code trasporta un codice di errore leggibile dalla macchina, così i client possono ramificare in base ad esso. Se un campo che solleva un'eccezione annulla solo se stesso o si propaga verso l'alto dipende dalla nullabilità: un campo non-null (posts: [Post!]!) che va in errore annulla invece il suo parent nullable più vicino.
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" },
});
}
// ...
},
},
};
Molti team modellano anche gli errori attesi (validazione, "email già in uso") come parte dello schema tramite tipi union/result, riservando l'array errors ai fallimenti inattesi — mantenendo pulita la tipizzazione del percorso felice.
Gli intervistatori verificano se sai che gli errori risiedono nel corpo insieme ai data parziali, che i codici vanno in extensions e che la nullabilità controlla quanto lontano si propaga un errore. Confondere gli errori di GraphQL con gli status code HTTP è un classico segnale che qualcuno ha usato solo REST.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona