GraphQL წარმატებული transport-ისთვის ყოველთვის აბრუნებს HTTP 200-ს; პრობლემები პასუხის სხეულში აისახება და არა სტატუს-კოდში. პასუხს აქვს ორი ზედა დონის გასაღები: data და errors, და ორივე შეიძლება ერთდროულად იყოს წარმოდგენილი — ეს არის ნაწილობრივი მონაცემი.
თუ ერთი ველის resolver გადააგდებს შეცდომას, ის ველი ხდება, -ში ჩანაწერი ემატება, მაგრამ დანარჩენი ყველა ველი მაინც წყდება. კლიენტი იღებს იმას, რაც წარმატდა, პლუს იმის აღწერას, რაც ჩავარდა.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // exactly which field failed
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
extensions.code ველი ატარებს მანქანურად წასაკითხ შეცდომის კოდს, ისე რომ კლიენტებმა მასზე დაყრდნობით შეძლონ განშტოება. თუ გადაგდებული ველი მხოლოდ საკუთარ თავს გახდის null-ს თუ ზემოთ ამოტივტივდება, დამოკიდებულია nullability-ზე: non-null ველი (posts: [Post!]!), რომელიც შეცდომას იძლევა, თავის უახლოეს nullable parent-ს გახდის 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" },
});
}
// ...
},
},
};
ბევრი გუნდი მოსალოდნელ შეცდომებსაც (ვალიდაცია, „email already taken") schema-ს ნაწილად აღწერს union/result ტიპებით, ხოლო errors მასივს მოულოდნელი ჩავარდნებისთვის ტოვებს — რაც happy-path-ის ტიპიზაციას სუფთად ინახავს.
ინტერვიუერები ამოწმებენ, იცი თუ არა, რომ შეცდომები სხეულში, ნაწილობრივ data-სთან ერთად ცხოვრობს, რომ კოდები extensions-ს ეკუთვნის და რომ nullability განსაზღვრავს, რამდენად შორს ამოტივტივდება შეცდომა. GraphQL-ის შეცდომების HTTP სტატუს-კოდებთან აღრევა კლასიკური ნიშანია იმისა, რომ ადამიანს მხოლოდ REST უხმარია.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა