GraphQL przy udanym transporcie zawsze zwraca HTTP 200; problemy są raportowane w treści odpowiedzi, a nie w kodzie statusu. Odpowiedź ma dwa klucze najwyższego poziomu: data i errors, i oba mogą wystąpić naraz — to dane częściowe.
Jeśli resolver jednego pola rzuci wyjątek, to pole staje się , do dodawany jest wpis, ale każde inne pole i tak zostaje rozwiązane. Klient dostaje to, co się udało, plus opis tego, co zawiodło.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Pole extensions.code przenosi maszynowo czytelny kod błędu, dzięki czemu klienci mogą się od niego rozgałęziać. To, czy zgłoszone pole zeruje tylko siebie, czy propaguje w górę, zależy od nullowalności: pole non-null (posts: [Post!]!), które błędnie się rozwiąże, zeruje najbliższego nullowalnego rodzica.
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" },
});
}
// ...
},
},
};
Wiele zespołów modeluje też oczekiwane błędy (walidacja, „email zajęty”) jako część schematu za pomocą typów unijnych/wynikowych, rezerwując tablicę errors na nieoczekiwane awarie — co utrzymuje czyste typowanie ścieżki sukcesu.
Rekruterzy badają, czy wiesz, że błędy żyją w treści z częściowymi data, że kody należą do extensions i że nullowalność decyduje, jak daleko propaguje się błąd. Mylenie błędów GraphQL z kodami statusu HTTP to klasyczny sygnał, że ktoś używał tylko REST.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj