مقارنة بين gRPC وREST

في الأطلس الكبير الإلكتروني، تُعد واجهات برمجة التطبيقات بمثابة الطرق التي تربط المدن والبلدات والشواطئ وغيرها من الوجهات. تُمكِّن واجهات برمجة التطبيقات تطبيقات البرامج من التواصل مع بعضها لتبادل البيانات والمزايا والوظائف. توصل تقرير Imperva لعام 2023 إلى أن حوالي 71% من حركة المرور على الإنترنت تتكون من استدعاءات واجهات برمجة التطبيقات، ما يدل على مدى أهمية هذه التقنية في عمل التطبيقات والمؤسسات الحديثة.

لا عجب أن تكون معرفة كيفية إنشاء واجهات برمجة تطبيقات مهارة أساسية لدى معظم المطورين. ولكن نظرًا إلى أهمية هذه البنية التحتية، فإن لها أشكالاً متعددة.

واستكمالاً لمثالنا، فإن الطريق السريع المكون من 12 حارة ليس "أفضل" من طريق سطحي ذي حارة واحدة؛ فهذا الطريق السريع من شأنه أن يدمر بنية الحي الحضري وسيكون هذا الطريق السطحي كارثة في منطقة ذات كثافة مرورية عالية. وبالمثل، تختلف الأنماط الهيكلية لإنشاء واجهات برمجة التطبيقات، مثل REST وgRPC، عن بعضها: فلكل منها نقاط قوة وضعف، ويُعد فهم نقاط القوة والضعف هذه أمرًا حيويًا لإنشاء بنية تحتية سليمة.

نقل الحالة التمثيلية، أو REST، هو مجموعة من مبادئ التصميم (أو القيود الهيكلية): واجهة موحدة، وفصل العميل عن الخادم، وانعدام الحالة، وقابلية التخزين المؤقت، وبنية النظام متعدد الطبقات، والتعليمات البرمجية عند الطلب (اختياري). يُطلق على واجهات برمجة التطبيقات التي تُنشأ باستخدام هذه المبادئ اسم REST APIs أو RESTful APIs.

يمكن أن تستخدم واجهات برمجة التطبيقات REST لغات برمجة وتنسيقات بيانات مختلفة، بشرط أن تتوافق مع مبادئ REST. وهي الطريقة الأكثر شيوعًا لإنشاء واجهات برمجة التطبيقات.

تستخدم واجهات برمجة التطبيقات REST طلبات HTTP (المعروفة أيضًا باسم أساليب HTTP) مثل GET وPOST وPUT وDELETE لأداء الوظائف الأساسية لقواعد البيانات. تُستخدم هذه العمليات لإنشاء سجلات الموارد وقراءتها وتحديثها وحذفها وغالبًا ما يشار إليها باسم "CRUD". تتحدد الموارد المتعلقة بالخادم من خلال عناوين URL التي تسمى نقاط النهاية.

على سبيل المثال، تستخدِم واجهة برمجة التطبيقات REST طلب GET لاسترداد سجل ما. يُنشئ طلب "POST" سجلاً جديدًا. يحدِّث طلب "PUT" سجلاً ويحذف طلب "DELETE" سجلاً. يمكن استخدام جميع أساليب HTTP في استدعاءات واجهة برمجة التطبيقات. تشبه واجهة برمجة تطبيقات REST المصممة جيدًا موقع ويب يعمل في متصفح ويب مزود بوظائف HTTP مدمجة.

يمكن تسليم معلومات الموارد إلى العميل بالعديد من تنسيقات المراسلة بما في ذلك JavaScript Object Notation (JSON) أو HTML أو XLT أو Python أو PHP أو نص عادي. يحظى JSON بشعبية كبيرة لأن البشر والآلات يمكنهم قراءته وهو غير مقيد بلغة برمجة محددة.

تعرف على المزيد حول الفرق بين REST وGraphQL

دعم المتصفحات: نظرًا إلى أن واجهات برمجة تطبيقات REST تستخدم HTTP/1.1 وأساليب HTTP القياسية، بالإضافة إلى تنسيقات مثل XML وJSON، فهي متوافقة مع المتصفحات. 

سهولة الاستخدام: بفضل بساطته وشهرته، يرى كثير من الناس أن REST أسهل في الفهم، خاصة للمبتدئين. تتوفر الأدوات والبرامج التعليمية والأدلة بكثرة على GitHub وغيرها من الأماكن.

المرونة: تتميز واجهات برمجة التطبيقات REST بوجود رابط ضعيف بين العميل والخادم. تتيح هذه المرونة إمكانية إجراء تغييرات بسهولة وسرعة أكثر: يمكن إجراء تغيير على أي من الجانبين من دون الحاجة إلى تغيير الآخر.

النظام البنائي الفائق: تتمتع واجهات برمجة التطبيقات REST بعدد كبير من الأدوات والدعم والتوثيق واسعي النطاق. على سبيل المثال، توفر مواصفات OpenAPI، أو OAS، تعريفًا قياسيًا خاصًا بالمجال لمعلمات واجهة برمجة التطبيقات REST وإمكاناتها. يتضمن الإصدار الأحدث من OAS، OAS 3.1، التوافق الكامل مع مخطط JSON، والتعريف الموحد الذي يستخدم معرّف SPDX وغير ذلك الكثير.

الاعتماد على HTTP/1.1: في حين أن استخدام REST لبروتوكول HTTP/1.1 يمنحه دعمًا عالميًا للمتصفحات وبعض التخصيص في العناوين، فإنه يحرم أيضًا واجهات برمجة التطبيقات REST من بعض مزايا الإصدار الأحدث HTTP/2. تتضمن تلك المزايا المفقودة التدفق ثنائي الاتجاه؛ حيث يدعم REST التدفق أحادي الاتجاه فقط، بمعنى أن الطلب الواحد يتبعه استجابة واحدة.

أبطأ وأقل كفاءة: كما هو الحال مع HTTP/1.1، توجد عيوب لاعتماد REST على تنسيقات مثل XML وJSON وكذلك مزايا. فهذه التنسيقات يمكن للبشر قراءتها، وهو أمر رائع، لكنها أيضًا ملفات كبيرة نسبيًا، ما يعني إرسال أبطأ.

يتطلب أدوات إضافية: قد يكون النظام البنائي لواجهة برمجة التطبيقات REST فائقًا، بل يجب أن يكون كذلك، نظرًا إلى أن بعض المزايا غير مدمجة في البنية. تتوفر إمكانات إنشاء التعليمات البرمجية، على سبيل المثال، في شكل مكونات إضافية لواجهة برمجة التطبيقات REST، ولكن هذه لا تزال خطوة إضافية، وذات تعقيد إضافي.

gRPC هو إطار عمل مفتوح المصدر طورته شركة Google في بداية الأمر كتنفيذ محدد لاستدعاء الإجراءات عن بُعد، أو RPC. تتولى مؤسسة Cloud Native Computing Foundation (CNCF) إدارته الآن.

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

بصفته نموذجًا للتفاعل بين العميل والخادم، غالبًا ما يُستخدم استدعاء الإجراءات عن بُعد في تطوير واجهات برمجة التطبيقات. في نموذج استدعاء الإجراءات عن بُعد، يتفاعل العميل مع وسيط يشار إليه عادةً باسم البرنامج المضاف. يعمل هذا البرنامج المضاف على تحويل البيانات من أجل عملية الإرسال، وبمجرد أن يتلقى النتائج المطلوبة من الخادم، يحولها مرة أخرى إلى التنسيق الأصلي من أجل تسليمها للعميل. لاستدعاء الإجراءات عن بُعد العديد من أنواع أُطر العمل المختلفة بما في ذلك XML-RPC وJSON-RPC.

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

يستخدم gRPC واجهة لغوية (IDL) تسمى بروتوكول التخزين المؤقت (Protobuf) لتحويل البيانات المنظمة إلى شكل ثنائي. ونظرًا إلى أن الشكل الثنائي أكثر إيجازًا من JSON أو XML، فإن هذا يتيح نقل حمولات أكبر بسرعات أعلى.

كما يستخدم gRPC بروتوكول HTTP/2، والذي يتيح التدفق ثنائي الاتجاه ويجعل gRPC خيارًا ممتازًا لواجهات برمجة التطبيقات في البيئات الموزعة (لا سيما تلك التي تتطلب التواصل في الوقت الفعلي)، وبُنى الخدمات المصغرة، وتطبيقات التدفق، واتصال أجهزة إنترنت الأشياء (IoT) .

السرعة: يحول gRPC، من خلال بروتوكول التخزين المؤقت، البيانات بين العديد من اللغات المختلفة، بما في ذلك Java وPython وRuby وغيرها الكثير، والحمولة الثنائية من أجل عملية الإرسال. وهذه التعليمات البرمجية خفيفة الوزن، لذا يقل وقت الإرسال وزمن الانتقال في عملية تبادل البيانات باستخدام واجهات برمجة التطبيقات gRPC.

إنشاء التعليمات البرمجية: يتضمن gRPC محولاً برمجيًا لبروتوكول التخزين المؤقت يسمى [protoc]، والذي يوفر مزايا إنشاء التعليمات البرمجية الأصلية. بمجرد تحديد بنية البيانات في ملف .proto، يمكن أن يُنشئ gRPC التعليمات البرمجية لكل من العميل والخادم.

دعم HTTP/2: بالاعتماد على بروتوكول النقل HTTP/2، يدعم gRPC أنواعًا مختلفة من التدفق. على سبيل المثال، يدعم التدفق ثنائي الاتجاه، حيث يمكن للعميل والخادم إرسال الرسائل بشكل مستقل في تدفق القراءة/الكتابة، بالإضافة إلى التدفق من جانب العميل ومن جانب الخادم.

المعترضات: تدعم gRPC البرمجيات الوسيطة المعروفة باسم المعترضات، والتي تسمح بزيادة الوظائف. يمكن تثبيت المعترضات لفرض الأمان والمصادقة وتحليل المقاييس وغير ذلك الكثير.

الإلغاء والمهلات: يدعم gRPC ميزة الإلغاء، أو ما يُعرف بالمهلات أو المواعيد النهائية: وهو وقت محدد يُلغى بعده الاستدعاء.

الحداثة والنظام البنائي: على الرغم من أن gRPC يتضمن مزايا إضافية مثل إنشاء التعليمات البرمجية، فإنه يُعد بنية جديدة نسبيًا، حيث ظهر إصداره الأولي في عام 2016. أدت هذه الحداثة إلى محدودية التوثيق والدعم مقارنة بالبُنى القديمة.

منحنى التعلم الحاد: يرى بعض المطورين أن منحنى تعلم gRPC أكثر حدة مقارنةً بمنحنى تعلم REST. يوفر تسلسل بياناته الثنائية اتصالاً فعالاً، ولكن لا يمكن للبشر قراءته.

غياب دعم المتصفحات: نظرًا إلى أن متصفحات الويب لا تدعم بروتوكول gRPC في الأصل، فمن غير الممكن استدعاء خدمة gRPC مباشرةً من تطبيق يستند إلى المتصفح. وتتمثل إحدى طرق التغلب على هذه المشكلة في استخدام وكيل مثل gRPC-Web. يعمل gRPC-Web بشكل أساسي كطبقة ترجمة بين بروتوكول HTTP الخاص بالمتصفح وبروتوكول gRPC.

تشترك REST وgRPC في العديد من العناصر وكلاهما يُستخدم لإنشاء أنظمة قابلة للتطوير. تشمل أوجه التشابه ما يلي:

بنية العميل/الخادم: gRPC وREST هما بنيتا عميل/خادم مع تنسيق الطلب-الاستجابة يُمكّنان العميل والخادم من التواصل وتبادل البيانات. في هذه البنية، يرسل العميل طلبًا ويستجيب الخادم بإرجاع البيانات المطلوبة أو تنفيذ الإجراء المطلوب.

مستقل عن المنصة: يُمكّن gRPC وREST الخدمات المبنية على منصات مختلفة بأنظمة تشغيل مختلفة من التواصل.

انعدام الحالة: يُعد كل من REST وgRPC منعدمي الحالة، بمعنى أن كل طلب يتضمن جميع المعلومات المطلوبة لإكماله. لا يحتاج الخادم إلى تخزين أي معلومات عن الطلبات السابقة.

دعم اللغات: نمط كلتا البنيتين غير مقيد بلغة محددة، ما يعني أنه يمكن استخدام واجهات برمجة التطبيقات هذه في التطبيقات المكتوبة بلغات برمجة مختلفة. وهذه الميزة تجعل كليهما قابلاً للنقل عبر بيئات البرمجة المختلفة.

استخدام HTTP: يعتمد كل من REST وgRPC على التواصل المستند إلى HTTP. لكن gRPC يستخدم بروتوكول HTTP/2، بينما يعتمد REST على بروتوكول HTTP/1.1. بالإضافة إلى ذلك، يجرد gRPC بروتوكول التواصل الأساسي HTTP/2، بينما يكون تواصل HTTP أقل تجريدًا في REST.

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

تنسيق البيانات: تستخدم واجهات برمجة التطبيقات REST بشكل أساسي تنسيقات نصية مثل JSON وXML. يستخدم gRPC بروتوكول التخزين المؤقت لتشفير البيانات بتنسيق ثنائي.

نمط التواصل: يدعم REST التواصل الأحادي فقط، ما يعني أن الطلب الواحد تتبعه استجابة واحدة. ويدعم gRPC أشياء أخرى، بما في ذلك التدفق ثنائي الاتجاه (يتبادل كل من العميل والخادم البيانات بشكل مستقل)، وتدفق الخادم (الطلب الواحد تتبعه استجابات متعددة) وتدفق العميل (تنتج عن الطلبات المتعددة استجابة واحدة).

نمط التصميم: يحتوي gRPC على تصميم موجه نحو الخدمة، حيث تُعرف عمليات الخادم القابلة للاستدعاء بأنها خدمات أو وظائف. في REST، يكون التصميم موجهًا نحو الموارد، حيث تُستخدم أساليب HTTP للوصول إلى موارد الخادم من خلال نقاط النهاية المحددة في عناوين URL.

الترابط: العميل والخادم في gRPC مرتبطان ارتباطًا وثيقًا، ما يعني أن كلاً من العميل والخادم يجب أن يكون لهما حق الوصول إلى ملف proto الخاص بالبرمجيات الوسيطة نفسه. أي تغيير في أحدهما يتطلب تغييرًا في الآخر. في REST، يكون الترابط ضعيفًا. وهذه الاستقلالية تعني أن التغييرات في أحد العناصر لا تؤثر في العنصر الآخر.

إنشاء التعليمات البرمجية: يوفر gRPC ميزة مدمجة لإنشاء التعليمات البرمجية؛ بينما لا يوفر REST ذلك، على الرغم من وجود مكونات إضافية متاحة.

التنفيذ: لا يتطلب REST أي برامج محددة ويدعم المتصفحات بالفعل. يتطلب gRPC برنامجًا محددًا على جانبي الخادم والعميل.

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

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

ويُفضل أيضًا استخدام REST بشكل عام لخدمات الويب وواجهات برمجة التطبيقات على شبكة الإنترنت، نظرًا إلى دعمه لبروتوكول HTTP/1.1 ودعمه للمتصفحات العالمية. بينما يُفضل استخدام gRPC بشكل عام لإجراء اتصالات بيانات أبسط. يمكن أن يؤدي ترابطه الضعيف وقلة تعقيده إلى تحسين قابلية التوسع في بنية النظام ويمكن أن يساعد على جعل البيئة أكثر مرونة بمرور الوقت. ومع ذلك، فإن هذه القدرة على التكيف تأتي على حساب الأداء. 

gRPC هي بنية أحدث نسبيًا، حيث يلجأ المطورون بشكل متزايد إلى استخدامها بفضل سرعتها وكفاءتها وأدواتها المدمجة. وغالبًا ما تُستخدم لتطبيقات التدفق في الوقت الفعلي وواجهات برمجة التطبيقات المعقدة التي تتطلب أداءً فائقًا ومعالجة أحمال البيانات العالية في الأنظمة الموزعة. وعلى الرغم من كونه أكثر تعقيدًا من REST، فإن استخدام بروتوكول HTTP/2 وبروتوكول التخزين المؤقت يمنح gRPC قابلية للتطور في الأداء بشكل أكبر. 

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

يُعد gRPC مثاليًا أيضًا لتوصيل عناصر إنترنت الأشياء (IOT) بواجهات برمجة التطبيقات الخلفية، وذلك لأن حمولاته صغيرة الحجم وزمن الانتقال القصير وكفاءته فائقة الأداء تتوافق مع التقنيات ذات الطاقة المنخفضة.