GraphQL luôn trả về HTTP 200 khi transport thành công; sự cố được báo trong thân response, không phải ở status code. Một response có hai key cấp cao nhất: data và errors, và cả hai có thể cùng xuất hiện — đó là partial data (dữ liệu một phần).
Nếu resolver của một field ném lỗi, field đó thành , một mục được thêm vào , nhưng mọi field khác vẫn resolve. Client nhận được phần thành công cộng với mô tả phần thất bại.
nullerrors{
"data": { "user": { "name": "Ada", "posts": null } },
"errors": [
{
"message": "Failed to load posts",
"path": ["user", "posts"], // chính xác field nào thất bại
"extensions": { "code": "DOWNSTREAM_TIMEOUT" }
}
]
}
Field extensions.code mang mã lỗi máy-đọc-được để client rẽ nhánh theo đó. Việc một field ném lỗi chỉ null chính nó hay lan lên trên phụ thuộc vào nullability: một field non-null (posts: [Post!]!) khi lỗi sẽ null parent nullable gần nhất thay vì chỉ null chính nó.
import { GraphQLError } from "graphql";
const resolvers = {
Mutation: {
transfer: (_p, args, ctx) => {
if (!ctx.user) {
// gắn một code ổn định để client switch theo; giấu chi tiết nội bộ
throw new GraphQLError("Not authenticated", {
extensions: { code: "UNAUTHENTICATED" },
});
}
// ...
},
},
};
Nhiều team còn mô hình hóa lỗi được dự đoán trước (validation, "email đã tồn tại") thành một phần của schema qua union/result type, dành mảng errors cho các thất bại ngoài dự kiến — giữ kiểu của happy-path sạch sẽ.
Người phỏng vấn dò xem bạn có biết lỗi nằm trong thân response cùng data một phần, rằng mã lỗi thuộc về extensions, và nullability kiểm soát mức độ lan của lỗi. Nhầm lỗi GraphQL với HTTP status code là dấu hiệu kinh điển của người mới chỉ dùng REST.
Thư viện câu hỏi phỏng vấn IT với đáp án chi tiết — từ Junior đến Senior.
Ủng hộ