GraphQL returnează întotdeauna HTTP 200 pentru un transport reușit; problemele sunt raportate în corpul răspunsului, nu în codul de status. Un răspuns are două chei de nivel superior: data și errors, iar ambele pot fi prezente simultan — asta înseamnă date parțiale.
Dacă resolverul unui câmp aruncă o excepție, acel câmp devine , se adaugă o intrare în , dar orice alt câmp se rezolvă în continuare. Clientul primește ce a reușit plus o descriere a ce a eșuat.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exact ce câmp a eșuat
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Câmpul extensions.code poartă un cod de eroare interpretabil de mașină, astfel încât clienții să poată ramifica după el. Faptul că un câmp care aruncă își anulează doar propria valoare sau se propagă în sus depinde de nullability: un câmp non-null (posts: [Post!]!) care eșuează anulează cel mai apropiat parent nullable în locul său.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// atașează un cod stabil pe care clienții pot comuta; ascunde detaliile interne
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Multe echipe modelează și erorile așteptate (validare, „email deja folosit") ca parte a schemei, prin tipuri union/result, rezervând array-ul errors pentru eșecurile neașteptate — păstrând curat sistemul de tipuri pe calea fericită.
Intervievatorii sondează dacă știi că erorile trăiesc în corp alături de data parțial, că codurile aparțin lui extensions și că nullability-ul controlează cât de departe se propagă o eroare. Confundarea erorilor GraphQL cu codurile de status HTTP este un semn clasic că cineva a folosit doar REST.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează