فهم الطلب وتكلفته
يستخدم المثال مخططاً افتراضياً: يجب وجود customer وorders وtotal في الواجهة الفعلية. قد يولد طلب واحد عدة قراءات على الخادم. يستطيع REST أيضاً تقديم استجابات مخصصة. نقطة HTTP واحدة شائعة مع GraphQL، لكنها ليست إلزامية لكل بنية.
query RecentOrders($id: ID!) {
customer(id: $id) {
name
orders(first: 5) {
nodes { id total }
}
}
}مقارنة مهمة ممثلة للاستخدام
- قِس البايتات والكمون والأخطاء وعمل الخادم للشاشة والصلاحيات نفسيهما وبأحجام واقعية.
- افحص تقسيم النتائج وتجميع القراءات لتقليل N+1 والتخزين المؤقت وعزل الحسابات.
- قيّم تطور المخطط وتوافق العملاء القدامى وجهد التشغيل. قد يكون الإبقاء على REST أبسط.
فرض الصلاحيات وحدود الحمل
صادق على الطلبات ثم تحقق من صلاحيات الكائنات والحقول في منطق العمل. حدّد أحجام القوائم والعمق والأسماء البديلة والعمليات المجمعة والتكلفة المقدرة. معدل الطلبات وحده لا يصف الحمل. إخفاء الاستبطان لا يعوض هذه الضوابط؛ اختبر الرفض والاستجابات الجزئية أيضاً.
المراجع الأساسية
إدارة مخطط GraphQL وتكلفة الاستعلام.
يتيح GraphQL للعملاء تحديد الحقول، ولكن هذه المرونة تتطلب ترخيصًا للكائنات والحقول. لا يغني تحديد حجم أو عمق الاستعلام وحده عن قياس الجهد المبذول في الاستعلام.
- اختبار الحقول الحساسة والكائنات المملوكة لحساب آخر.
- تحديد ومراقبة التكلفة والعمق وحجم الطلبات للخدمة.
- مراجعة تغييرات مخطط الإصدار واختبار العملاء القدامى.
المصدر الأساسي: OWASP — GraphQL Cheat Sheet. المنهج المرتبط: اقرأ الدليل العملي.
ETag وتخزين HTTP المؤقت والتعديلات المتزامنة
الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.
REST and GraphQL: separate representation and authorisation
An HTTP ETag applies to a selected representation. It is neither permission for every returned object nor a universal consistency contract for GraphQL entities.
- Define which response variants have their own validators.
- Test object and field access independently from HTTP conditions.
- Do not automatically apply the PUT scenario to a GraphQL mutation; specify its concurrency contract.
Explore ETag comparisons and the simulator →
References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3
