REST vs GraphQL vs gRPC: إطار عمل القرار لعام 2026

يبدأ فريقك خدمة جديدة. يفتح شخص ما سلسلة رسائل Slack: "هل يجب أن نستخدم GraphQL؟" شخص آخر يجيب مع رابط إلى معيار gRPC. ينقسم الخيط إلى ثلاثة معسكرات. وبعد ساعتين لم يكن هناك قرار.

المشكلة ليست في نقص المعلومات. المشكلة هي عدم وجود معايير. REST وGraphQL وgRPC لكل منهما حل شكل مختلف من المشكلة. اختر الخيار الخطأ وستدفع الضريبة على كل طلب لسنوات. اختر الخيار المناسب وستختفي الهندسة المعمارية في الخلفية.

يمنحك هذا الدليل إطارًا ملموسًا لاتخاذ القرار، وليس "الأمر يعتمد على ذلك". يحصل كل بروتوكول على محدد استخدم الحالة التي يفوز فيها، ومثال التعليمات البرمجية الذي يمكنك تشغيله، وجدول المقارنة الذي يمكنك الدخول إليه وثيقة التصميم.

إطار 30 ثانية

ابدأ بثلاثة أسئلة:

1. من يتصل بواجهة برمجة التطبيقات (API) هذه؟ المطورين الخارجيين، عملاء الواجهة الأمامية الخاصة بك، أو الخدمات الداخلية؟
2. كم عدد أشكال البيانات التي يحتاجها العميل؟ شكل واحد ثابت أم عدة أشكال؟
3. ما الذي يهم أكثر: إمكانية التخزين المؤقت، أو مرونة الاستعلام، أو الإنتاجية الأولية؟

يتم تعيين الإجابات مباشرة إلى البروتوكول:

• استراحة يفوز عندما يكون الجمهور خارجيًا، ويكون شكل البيانات ثابتًا، ويكون التخزين المؤقت مهمًا.
• GraphQL يفوز عندما يحتاج العديد من العملاء إلى شرائح مختلفة من نفس الرسم البياني للبيانات.
• جي آر بي سي يفوز عندما تتحدث الخدمات الداخلية مع بعضها البعض وتكون الإنتاجية أكثر أهمية من سهولة القراءة البشرية.

هنا هو نفس منطق الكود:

REST: الافتراضي العالمي

يقوم REST بتعيين العمليات إلى أفعال HTTP والموارد إلى عناوين URL. تحتوي كل لغة برمجة على عميل HTTP. يفهم كل CDN رؤوس ذاكرة التخزين المؤقت. وقد استخدم كل مطور curl.

REST هو الاختيار الصحيح لواجهات برمجة التطبيقات العامة حيث يمكنك التحكم في شكل البيانات ويتوقع العملاء استقرارًا، نقاط النهاية الموثقة. تستخدم جميع نقاط نهاية واجهة برمجة التطبيقات (API) التي يزيد عددها عن 150 نقطة في botoi REST. هنا بحث DNS:

إجابة:

الطلب عبارة عن مشاركة واحدة. الاستجابة هي كائن JSON مسطح. يمكنك اختباره باستخدام الضفيرة أو الأنابيب من خلال jqأو اتصل بها من أي لغة باستخدام fetch. لا يوجد ملف مخطط لتجميعه، لا توجد لغة استعلام لتعلمها، ولا توجد خطوة لإنشاء التعليمات البرمجية.

حيث يشرق REST

• واجهات برمجة التطبيقات للمطورين العامة. يتوقع مطورو الطرف الثالث REST. تكلفة الإعداد هي صفر.
• الموارد القابلة للتخزين المؤقت. يعمل التخزين المؤقت لـ HTTP في كل طبقة: المتصفح، CDN، الوكيل العكسي. أ GET /users/123 الاستجابة برؤوس ذاكرة التخزين المؤقت المناسبة لا تكلف شيئًا عند تكرار الطلبات.
• تكاملات Webhook. خطافات الويب هي طلبات HTTP POST. REST يناسب النموذج العقلي.
• عمليات CRUD البسيطة. عندما تقوم كل نقطة نهاية بشيء واحد باستخدام شكل إدخال واحد وشكل إخراج واحد، فإن REST لا يضيف أي حمل.

حيث يقصر REST

• الإفراط في الجلب. لا يزال تطبيق الهاتف المحمول الذي يحتاج إلى 3 حقول من ملف تعريف المستخدم يقوم بتنزيل الكائن الكامل المكون من 40 حقلاً.
• أقل من الجلب. تقوم لوحة المعلومات التي تعرض المستخدم وفريقه وأنشطته الأخيرة بإجراء 3 مكالمات HTTP متسلسلة. الكمون يضيف ما يصل.
• لا يوجد تطور مخطط مدمج. عناوين URL لإصدارك (/v1/, /v2/) أو أضف حقولًا ونأمل أن يتجاهل العملاء المفاتيح غير المعروفة.

GraphQL: الاستعلامات التي يحركها العميل

يتيح GraphQL للعميل تحديد الحقول التي يحتاجها بالضبط في طلب واحد. يكشف الخادم مخطط مكتوب. يكتب العميل استعلامًا مقابل هذا المخطط ويحصل على استجابة على شكل مطابق.

توضح واجهة برمجة التطبيقات العامة لـ GitHub هذا جيدًا. استعلام واحد يجلب اسم المستخدم الخاص بك وأفضل 3 مستودعات مع عدد النجوم واللغة الأساسية. في REST، سيتطلب ذلك مكالمتين على الأقل.

إجابة:

طلب العميل name, stargazerCount، و primaryLanguage. أعاد الخادم تلك الحقول بالضبط. لم يتم نقل أي بيانات إضافية. لا يوجد طلب ثاني

حيث يتألق GraphQL

• تطبيقات الجوال. عرض النطاق الترددي محدود. حجم الحمولة مهم. يزيل GraphQL الجلب الزائد على كل شاشة.
• لوحات المعلومات وطرق عرض التجميع. يمكن لاستعلام واحد سحب البيانات من المستخدمين والأوامر والمخزون في رحلة ذهابًا وإيابًا واحدة.
• التكرار السريع للواجهة الأمامية. تقوم فرق الواجهة الأمامية بتغيير استعلاماتها دون انتظار فرق الواجهة الخلفية لإنشاء نقاط نهاية جديدة.
• كتابة قوية. المخطط هو العقد. أدوات إنشاء التعليمات البرمجية مثل GraphQL Code Generator تنتج أنواع TypeScript منها.

حيث يقصر GraphQL

• التخزين المؤقت. كل استعلام هو منشور ل /graphql. لا يعمل التخزين المؤقت لـ HTTP على مستوى CDN أو المستعرض بدون طبقة الاستعلام المستمر أو الاستعلامات المستندة إلى GET.
• سطح أمني. يمكن للعملاء كتابة استعلامات باهظة الثمن تربط بيانات متداخلة بعمق. أنت بحاجة إلى تحليل تكلفة الاستعلام وتحديد العمق لمنع إساءة الاستخدام.
• منحنى التعلم. يحتاج المطورون إلى تعلم لغة الاستعلام وتصميم المخطط والمحللات وأنماط DataLoader. وقت التكثيف أعلى من REST.
• استعلامات N+1. تؤدي أنماط المحلل الساذجة إلى تشغيل استعلام قاعدة بيانات واحد لكل عنصر في القائمة. يعمل تجميع DataLoader على إصلاح هذه المشكلة، ولكن يجب عليك إنشائها بنفسك.

gRPC: السرعة الداخلية

يستخدم gRPC مخازن البروتوكول المؤقتة للتسلسل وHTTP/2 للنقل. أنت تحدد خدمتك العقد في أ .proto الملف، وإنشاء تعليمات برمجية للعميل والخادم، والحصول على مكالمات RPC آمنة من النوع مع الحمولات الثنائية.

من هذا التعريف، protoc ينشئ بذرة العميل وواجهات الخادم في Go وJava و Python أو Rust أو C++ أو عشرات اللغات الأخرى. يعالج الكود الذي تم إنشاؤه التسلسل، وإلغاء التسلسل، وتأطير HTTP/2.

حيث يتألق gRPC

• التواصل من خدمة إلى خدمة. تستفيد الخدمات الصغيرة الداخلية التي تتبادل الرسائل عالية التردد من التسلسل الثنائي والتدفقات المتعددة.
• عقود صارمة. ال .proto الملف هو المصدر الوحيد للحقيقة. يتم اكتشاف التغييرات العاجلة في وقت الترجمة، وليس في وقت التشغيل.
• تدفق ثنائي الاتجاه. يدعم gRPC تدفق الخادم وتدفق العميل والتدفق ثنائي الاتجاه. تتلاءم ميزات الوقت الفعلي مثل خلاصات المعاملات المباشرة بشكل طبيعي.
• البيئات متعددة اللغات. يمكن لخدمة Go الاتصال بخدمة Python من خلال بذرة تم إنشاؤها بدون رمز تسلسل يدوي.

حيث يقصر gRPC

• دعم المتصفح. لا يمكن للمتصفحات إجراء مكالمات gRPC أصلية. يضيف وكيل grpc-web طبقة من التعقيد وزمن الوصول.
• سهولة القراءة البشرية. الحمولات الثنائية غير قابلة للفحص curl أو أدوات تطوير المتصفح. يتطلب تصحيح الأخطاء أدوات متخصصة مثل grpcurl أو بلوم آر بي سي.
• نضج النظام البيئي. تتمتع REST بعقود من الأدوات: Postman، وSwagger، وبوابات API، ومحددات الأسعار. تنمو أدوات gRPC ولكن ليس على نفس المستوى.
• منحنى التعلم. يجب أن تتعلم الفرق المخازن المؤقتة للبروتوكول، وبناء جملة proto3، وخطوط أنابيب إنشاء التعليمات البرمجية، وأنماط معالجة الأخطاء الخاصة بـ gRPC.

جدول المقارنة

أمثلة على القرارات في العالم الحقيقي

الشريط: الراحة للمدفوعات

يعالج Stripe مدفوعات بمليارات الدولارات من خلال REST API. نقاط النهاية الخاصة بهم تتبع ما يمكن التنبؤ به الأنماط: POST /v1/payment_intents, GET /v1/charges/:id. كل مطور من يدمج Stripe يعرف HTTP. الاحتكاك على متن الطائرة يقترب من الصفر. اختار الشريط REST لأنه جمهورهم هو المطورين الخارجيين الذين يحتاجون إلى نقاط نهاية مستقرة وموثقة وقابلة للتخزين المؤقت.

GitHub: GraphQL لأدوات المطورين

تم ترحيل GitHub من REST (v3) إلى GraphQL (v4) لأن عملائهم (تطبيقات سطح المكتب، وتطبيقات الهاتف المحمول، عمليات تكامل الجهات الخارجية) تحتاج جميعها إلى بيانات مختلفة من نفس الكائنات. تحتاج أداة CI إلى الالتزام تشغيل الحالة والتحقق. يحتاج تطبيق إدارة المشروع إلى المشكلات والتصنيفات والمكلفين. تطبيق جوال يحتاج إلى الحد الأدنى من عرض الملف الشخصي. لا يمكن لنقطة نهاية REST واحدة أن تخدم الثلاثة جميعًا دون جلب مبالغ كبيرة.

جوجل: gRPC للخدمات الداخلية

قامت Google ببناء gRPC (يرمز الحرف "g" إلى كلمة مختلفة لكل إصدار) للتعامل مع خدمة الخدمة الداخلية التواصل على نطاق واسع. عندما تقوم شبكة الخدمة الخاصة بك بمعالجة الملايين من عمليات RPCs في الثانية، يظهر الفرق بين تحليل نص JSON وإلغاء التسلسل الثنائي لـ Protocol Buffer. اختارت Google gRPC بسبب ذلك الجمهور داخلي، والعقود صارمة، والإنتاجية هي القيد الأساسي.

لماذا اختار botoi REST لأكثر من 150 نقطة نهاية

تخدم واجهة برمجة تطبيقات botoi نقاط نهاية مساعدة مستقلة: عمليات بحث DNS، والتحقق من صحة البريد الإلكتروني، وتنسيق JSON، ورمز الاستجابة السريعة الجيل، حساب التجزئة. تأخذ كل نقطة نهاية مدخلات محددة وترجع مخرجات محددة. لا يوجد رسم بياني للبيانات العلائقية يربط سجل DNS برمز QR.

ثلاثة عوامل جعلت REST الاختيار الواضح:

• دعم العملاء العالمي. يقوم المطورون باستدعاء botoi من Node.js، وPython، وGo، وRuby، وPHP، نصوص شل ووكلاء الذكاء الاصطناعي. يعمل REST في كل منهم بدون إعداد.
• إمكانية التخزين المؤقت. الحصول على نقاط النهاية للموارد الثابتة (مثل عمليات البحث عن البلدان أو قوائم العملات) الاستفادة من التخزين المؤقت لـ HTTP في طبقة CDN. يؤدي هذا إلى إبقاء أوقات الاستجابة أقل من 20 مللي ثانية للطلبات المتكررة.
• قابلية الاكتشاف. تحتوي كل نقطة نهاية على عنوان URL ثابت وإدخال مواصفات OpenAPI وتفاعلي المستندات عبر Scalar. يقوم المطورون الجدد بالعثور على نقاط النهاية واختبارها في أقل من دقيقة.

قد يضيف GraphQL التعقيد دون فائدة. لا يوجد رسم بياني للاستعلام لاجتيازه. سوف يفعل gRPC استبعاد عملاء المتصفح والبرامج النصية Shell. REST هي الأداة المناسبة لهذا النوع من المشكلة.

خلط البروتوكولات في نظام واحد

ينطبق الإطار على كل حدود، وليس على كل مؤسسة. تجمع العديد من أنظمة الإنتاج بين البروتوكولات:

• طبقة واجهة برمجة التطبيقات الخارجية: استراحة. يتوقع مطورو الطرف الثالث وخطافات الويب استخدام HTTP + JSON.
• بوابة مواجهة العميل: GraphQL. يقوم عملاء الهاتف المحمول والويب بالاستعلام عن بوابة تقوم بتجميع البيانات من خدمات متعددة.
• شبكة الخدمة الداخلية: جي آر بي سي. تتواصل خدمات الواجهة الخلفية مع الحمولات الثنائية والعقود الصارمة.

وهذا ليس تعقيدا من أجل التعقيد. كل حدود لها جمهور مختلف مع مختلف القيود. يجب أن يتوافق البروتوكول مع القيد، وليس العكس.

قائمة مراجعة القرار

انسخ هذا في مستند التصميم الخاص بك. أجب عن كل سؤال، وسيصبح اختيار البروتوكول واضحًا.

1. من هم مستهلكو API؟ المطورون الخارجيون (REST)، فريق الواجهة الأمامية الخاص بك (GraphQL)، الخدمات الداخلية (gRPC).
2. كم عدد أشكال البيانات التي يطلبها العملاء؟ شكل واحد (REST)، أشكال متعددة (GraphQL)، عقود ثابتة (gRPC).
3. هل التخزين المؤقت لـ HTTP مهم؟ نعم (REST)، أحيانًا (GraphQL مع الجهد)، لا (gRPC).
4. هل تحتاج إلى البث؟ لا (REST جيد)، الاشتراكات (GraphQL)، ثنائي الاتجاه (gRPC).
5. ما هي اللغات التي يستخدمها العملاء؟ كل شيء (REST)، ثقيل JS/TS (أدوات GraphQL هي الأقوى هنا)، متعدد اللغات مع إنشاء التعليمات البرمجية (gRPC).
6. ما هي الخبرة الحالية للفريق؟ إذا لم يكن أحد يعرف المخازن المؤقتة للبروتوكول، فإن تكلفة gRPC مرتفعة للغاية. إذا لم يكن أحد يعرف أدوات حل GraphQL، فتوقع شهرًا من التعلم قبل الاستعداد للإنتاج.

أخطاء شائعة يجب تجنبها

• اختيار GraphQL لأنه يبدو جديدًا. يضيف GraphQL تعقيد المحلل والاستعلام تحليل التكلفة وتخفيف N+1. إذا كانت واجهة برمجة التطبيقات لديك تحتوي على 10 نقاط نهاية CRUD بأشكال ثابتة، فإن REST يفعل ذلك نفس الوظيفة مع رمز أقل.
• اختيار gRPC لواجهة برمجة التطبيقات العامة. لا يمكن للمستخدمين الاتصال بـ gRPC من المتصفح، من حليقة، أو من أداة منخفضة التعليمات البرمجية. سينتهي بك الأمر ببناء بوابة REST أمامها على أي حال.
• اختيار REST لرسم بياني معقد للبيانات. إذا طلب فريق الواجهة الأمامية الخاص بك 5 جديدة نقاط النهاية "الملخصة" لكل سباق لأن النقاط الموجودة تُرجع الكثير من البيانات أو القليل جدًا منها، هذه علامة على أن GraphQL سيقلل من أعباء التنسيق.
• إهمال خبرة الفريق. أسرع بروتوكول للشحن هو بروتوكول فريقك يعرف بالفعل. سيقضي الفريق الذي يتقن REST والذي يتحول إلى gRPC أسابيع في استخدام الأدوات من قبل كتابة منطق الأعمال.