ما الفرق بين gRPC وREST؟
gRPC وREST هما طريقتان يمكنك من خلالهما تصميم واجهة برمجة تطبيقات. تتيح واجهة برمجة التطبيقات (API) لاثنين من المكونات البرمجية الاتصال ببعضهما باستخدام مجموعة من التعريفات والبروتوكولات. في gRPC، يستدعي أحد المكونات (العميل) وظائف محددة في مكون برمجي آخر (الخادم). في REST، يطلب العميل البيانات أو يحدّثها على الخادم بدلاً من الاتصال بالوظائف.
ما المقصود بـ gRPC؟
ما المقصود باستدعاء الإجراء عن بُعد (RPC)؟
في استدعاء الإجراء عن بُعد (RPC)، تعمل اتصالات الخادم-العميل كما لو كانت طلبات واجهة برمجة تطبيقات العميل هي عملية محلية، أو كان الطلب عبارة عن تعليمة برمجية للخادم الداخلي.
في استدعاء الإجراء عن بُعد (RPC)، يُرسل العميل طلبًا إلى عملية على الخادم الذي يتعامل دائمًا مع الاستدعاءات البعيدة. في الطلب، يحتوي على وظيفة الخادم المراد استدعاؤها، إلى جانب أي مَعْلمات مطلوب تمريرها. تستخدم واجهة RPC API بروتوكولًا مثل HTTP أو TCP أو UDP بوصفها آلية أساسية في تبادل البيانات.
كيف يختلف gRPC عن RPC؟
gRPC هو نظام ينفذ استدعاء الإجراء عن بُعد (RPC) التقليدي بجانب اشتماله على العديد من التحسينات. على سبيل المثال، يستخدم gRPC بروتوكول التخزين المؤقت والبروتوكول HTTP 2 لنقل البيانات.
كما أنه يستخلص آلية تبادل البيانات من المطور. على سبيل المثال، تتطلب إحدى عمليات تنفيذ واجهة RPC API التي تُستخدم على نطاق واسع، وهي الواجهة OpenAPI، من المطورين تعيين مفاهيم استدعاء الإجراء عن بُعد (RPC) إلى بروتوكول HTTP. لكن gRPC يستخلص اتصال HTTP الأساسي. تعمل هذه التحسينات على جعل gRPC أسرع وأسهل في التنفيذ وأكثر ملاءمةً للويب من عمليات تنفيذ RPC الأخرى.
ما المقصود بنقل الحالة التمثيلية (REST)؟
REST هو أحد نُهُج تصميم البرامج الذي يحدد مجموعةً من القواعد لتبادل البيانات بين مكونات البرنامج. إنه يعتمد على البروتوكول HTTP، وهو بروتوكول الاتصال القياسي للويب. تدير واجهات RESTful API الاتصالات بين العميل والخادم من خلال أفعال HTTP، مثل POST، وGET، وPUT، وDELETE الخاصة بعمليات الإنشاء والقراءة والتحديث والحذف. يتحدد المورد جانب الخادم بواسطة عنوان URL يُعرف باسم نقطة النهاية.
يعمل REST على النحو التالي:
- يقدم العميل طلبًا لإنشاء مورد أو تعديله أو حذفه على الخادم
- يحتوي الطلب على نقطة نهاية المورد وقد يتضمن أيضًا مَعْلمات إضافية
- يستجيب الخادم ويعيد المورد بأكمله إلى العميل بمجرد اكتمال العملية
- تحتوي الاستجابة على بيانات بتنسيق JSON ورموز الحالة
واجهات برمجة التطبيقات التي تم إنشاؤها باستخدام إرشادات REST تسمى واجهات RESTful API أو واجهات REST API.
لماذا تستخدم المنظمات gRPC وREST؟
gRPC وREST هما طريقتان مختلفتان لتطوير واجهات برمجة التطبيقات.
تعمل واجهة برمجة التطبيقات بطريقة مشابهة لطلب الطعام من أحد المطاعم باستخدام قائمة طعام. في أي مطعم، يمكن للعميل (الجهاز العميل) طلب الطعام من القائمة (واجهة برمجة التطبيقات)، التي تتضمن مجموعةً محددةً من الأطباق. يُرسل هذا الطلب إلى المطبخ (الخادم) الذي يقوم بإعداد الطبق المطلوب وإرساله إلى العميل. لا يحتاج العميل إلى معرفة كيف يُعد المطبخ الطلب، بل إنه لا ينتظر سوى تحضير طلبه وإرجاعه. إن توحيد تنسيقات القوائم يعني أن العملاء والمطابخ يعرفون كيفية استخدامها.
بدون واجهات برمجة التطبيقات، لن تكون هناك اتفاقية مشتركة حول كيفية اتصال التطبيقات أو خدمات البرامج المختلفة. يحتاج مبرمجو تطبيقين منفصلين إلى التحدث مع بعضهم لتحديد كيفية إنشاء تبادل البيانات في كل مرة.
توجد أنواع مختلفة من بنيات واجهات برمجة التطبيقات مثل gRPC وREST، حيث إن تنوع الأنواع يكون أفضل لتنوع حالات الاستخدام داخل المنظمة. يجب أن يختار أحد مصممي واجهة برمجة التطبيقات بنية الخادم-العميل المفضلة له بناءً على متطلبات النظام.
ما أوجه التشابه بين gRPC وREST؟
يشترك REST وgRPC في بعض أوجه التشابه الأساسية (الطبيعية) بوصفهما نُهج تصميم خاصة بواجهات برمجة التطبيقات.
آلية تبادل البيانات
يسمح كلاهما لمكوني البرنامج، العميل والخادم، بالاتصال وتبادل البيانات بناءً على مجموعة مشتركة من القواعد. تنطبق هذه القواعد بغض النظر عن آلية عمل كل مكون من مكونات البرنامج داخليًا.
الاتصال المستند إلى HTTP
يقوم كلاهما بتمرير البيانات عبر آلية استجابة-طلب باستخدام البروتوكول HTTP، وهو بروتوكول الاتصال الفعّال والمفضل في الويب. ومع ذلك، في gRPC، يكون هذا البروتوكول مخفيًا عن المطور بينما في REST يكون أكثر وضوحًا.
مرونة التنفيذ
يُمكنك تنفيذ كل من REST وgRPC في مجموعة واسعة من لغات البرمجة. وهذه الصفة تجعلهما يتسمان بالمرونة العالية في بيئات البرمجة. وهذا يؤدي إلى التشغيل البيني الأمثل مع دعم شبه شامل.
الملاءمة للأنظمة الموزعة القابلة للتوسع
يستخدم كل من gRPC وREST ما يلي:
- اتصال غير متزامن، وبالتالي يمكن للعميل والخادم الاتصال بدون مقاطعة عمليات التشغيل
- تصميم عديم الحالة، ولذلك لا يضطر الخادم إلى تذكر حالة العميل
هذا يعني أنه يمكن للمطورين استخدام gRPC وREST في بناء أنظمة تتعامل مع الأخطاء تشمل عددًا كبيرًا من الطلبات المتزامنة. يمكنك إنشاء أنظمة موزعة قابلة للتوسع تشمل العديد من العملاء.
مبادئ التصميم: gRPC مقابل REST
بينما يقدم REST وgRPC وظيفةً مماثلةً، إلا أن النماذج الأساسية تختلف بشكل كبير في بنيتها.
نموذج الاتصال
باستخدام واجهة REST API، يُرسل العميل طلب REST API واحدًا إلى الخادم، ثم يرسل الخادم ردًا في صورة استجابة واحدة. يجب أن ينتظر العميل حتى يستجيب الخادم قبل متابعة العمليات. هذه الآلية هي نموذج طلب-استجابة وهي عبارة عن اتصال بيانات أحادي (واحد إلى واحد).
في المقابل، مع gRPC، يمكن للعميل إرسال طلب واجهة برمجة تطبيقات واحد أو عدة طلبات إلى الخادم وهذا ينتج عنه رد واحد أو عدة ردود من الخادم. قد تكون اتصالات البيانات أحادية (واحد إلى واحد)، أو تدفق الخادم (واحد إلى متعدد)، أو تدفق العميل (متعدد إلى واحد)، أو تدفق ثنائي الاتجاه (متعدد إلى متعدد). هذه الآلية هي نموذج اتصال عميل-استجابة وهي آلية ممكنة لأن gRPC يعتمد على HTTP 2.
عمليات قابلة للاستدعاء على الخادم
في واجهة gRPC API، يتم تعريف عمليات الخادم القابلة للاستدعاء بواسطة الخدمات، وتُعرف أيضًا باسم الوظائف أو الإجراءات. يستدعي عميل gRPC هذه الوظائف كما لو كنت تستدعي وظيفة داخلية في أحد التطبيقات. يُعرف هذا بالتصميم الموجه نحو الخدمة. إليك مثال:
createNewOrder(customer_id, item_id, item_quantity) -> order_id
في REST، تتوفر مجموعة محدودة من أفعال طلبات HTTP التي يمكن للعميل استخدامها على موارد الخادم المحددة بواسطة عنوان URL. يقوم العميل باستدعاء المورد نفسه. يُعرف هذا بالتصميم الموجه للكيان. يتوافق التصميم الموجه للكيان جيدًا مع أساليب البرمجة الموجهة للكائن. إليك مثال:
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id
بينما يمكنك تصميم واجهات gRPC API بأسلوب موجه نحو الكيان، فإن هذا ليس قيدًا على النظام نفسه.
تنسيق تبادل البيانات
مع واجهة REST API، يتم التعبير عن هياكل البيانات التي تُمرّر بين المكونات البرمجية عادةً بتنسيق تبادل البيانات JSON. من الممكن تمرير تنسيقات بيانات أخرى مثل XML وHTML. يتميز JSON بسهولة القراءة والمرونة، على الرغم من أنه يجب تسلسله وترجمته إلى لغة برمجة.
وفي المقابل ووفقًا للإعدادات الافتراضية، يستخدم gRPC تنسيق بروتوكول التخزين المؤقت (Protobuf)، على الرغم من أنه يوفر أيضًا دعم JSON الأصلي. يُعرّف الخادم هيكل بيانات باستخدام لغة وصف واجهة (IDL) بروتوكول التخزين المؤقت في ملف مواصفات أولية. ثم يقوم gRPC بإجراء تسلسل البنية إلى تنسيق ثنائي ثم إلغاء تسلسلها إلى أي لغة برمجة محددة. هذه الآلية تجعله أسرع من استخدام JSON، الذي لا يتم ضغطه أثناء الإرسال. لا يمكن قراءة بروتوكول التخزين المؤقت بواسطة العنصر البشري، على عكس واجهة REST API المستخدمة مع JSON.
الاختلافات الأساسية الأخرى: gRPC مقابل REST
الاختلافات الأساسية الأخرى: gRPC مقابل REST
بجانب نمط التصميم، توجد اختلاف أساسية أخرى بين gRPC وREST.
اقتران العميل-الخادم
يتم اقتران REST بشكل غير محكم، ما يعني أن العميل والخادم لا يحتاجان إلى معرفة أي شيء عن تنفيذ الآخر. هذا الاقتران غير المحكم يجعل من السهل تطوير واجهة برمجة التطبيقات بمرور الوقت. هذا لأن التغيير في تعريفات الخادم لا يتطلب بالضرورة تغيير التعليمة البرمجية في العميل.
يتم اقتران gRPC بشكل محكم، ما يعني أنه يجب أن يكون لدى العميل والخادم حق الوصول إلى نفس ملف النموذج الأولي. أي تحديثات للملف تتطلب تحديثات في كل من الخادم والعميل.
إنشاء التعليمة البرمجية
يقدم gRPC مجموعةً مدمجةً من ميزات إنشاء التعليمات البرمجية الأصلية بجانب العميل وجانب الخادم. وهي متوفرة بلغات متعددة تتنوّع حسب البروتوكول، المُحول البرمجي لبروتوكولات التخزين المؤقت. بعد تحديد البنية في ملف النموذج الأولي، يُنشئ gRPC التعليمة البرمجية من جانب العميل ومن جانب الخادم. يؤدي إنشاء التعليمات البرمجية إلى جعل تطوير واجهات برمجة التطبيقات أقل استهلاكًا للوقت.
من ناحية أخرى، لا يقدم REST أي آليات مدمجة خاصة بإنشاء التعليمات البرمجية، ولذلك يجب على المطورين استخدام أدوات إضافية تابعة لجهات خارجية إذا كانوا بحاجة إلى هذه الميزة. تعرف على المزيد حول إنشاء الأكواد.
التدفق ثنائي الاتجاه
تقدم gRPC اتصالات تدفق ثنائية الاتجاه. هذا يعني أنه يمكن لكل من العميل والخادم إرسال العديد من الطلبات والاستجابات واستقبالها في وقت واحد على اتصال واحد.
لا يقدم REST هذه الميزة.
حالات استخدام gRPC مقابل REST
تُعد REST في الوقت الحالي بنية واجهة برمجة التطبيقات الأكثر شيوعًا في خدمات الويب وبنيات الخدمات المصغرة. تعود شهرة REST إلى سهولة تنفيذها وتعيين بنية البيانات وقابلية القراءة والمرونة. من السهل على المبرمجين الجدد البدء في تطوير واجهات RESTful API لتطبيقاتهم، سواءً لتطوير خدمات الويب أو الخدمات المصغرة الداخلية.
فيما يلي حالات استخدام لإحدى واجهات REST API:
- البنيات المستندة إلى الويب
- واجهات برمجة التطبيقات العامة لسهولة فهمها من قِبل مستخدمين خارجيين
- اتصالات البيانات البسيطة
على عكس REST، تم تصميم gRPC خصيصًا للسماح للمطورين بإنشاء واجهات برمجة تطبيقات عالية الأداء لبنيات الخدمات المصغرة عبر مراكز بيانات موزعة. إنها مناسبة بشكل أفضل للأنظمة الداخلية التي تتطلب التدفق في الوقت الفعلي وتحميلات البيانات الكبيرة. يُعد gRPC أيضًا مناسبًا جيدًا لبنيات الخدمات المصغرة التي تضم العديد من لغات البرمجة عندما يكون من غير المحتمل أن تتغير واجهة برمجة التطبيقات بمرور الوقت.
تُعد واجهة gRPC API أفضل لحالات الاستخدام التالية:
- الأنظمة عالية الأداء
- تحميلات البيانات العالية
- تطبيقات الوقت الفعلي أو تطبيقات التدفق
ملاحظة حول تطوير برامج الويب
في حين أن HTTP هو بروتوكول الويب الأساسي، توجد إصدارات مختلفة من HTTP وهذه الإصدارات تتفاوت في درجات اعتمادها عبر متصفحات الويب وخوادم الويب.
تستخدم واجهة gRPC API دائمًا HTTP 2، بينما واجهة REST API تستخدم عادةً HTTP 1.1، وهو لا يتطابق مع البروتوكول HTTP. على الرغم من أن HTTP 2 أصبح الآن من بين بروتوكولات الويب الشائعة، إلا أنه لا يحتوي على دعم شامل للمتصفحات، على عكس البروتوكول HTTP 1.1. يمكن لمحدودية دعم المتصفحات أن تجعل gRPC خيارًا أقل جاذبيةً للمطورين الذين يرغبون في دعم تطبيقات الويب.
ملخص الاختلافات: gRPC مقابل REST
| واجهة برمجة تطبيقات gRPC |
REST API |
|
| ما التعريف؟ |
نظام لإنشاء واجهات برمجة التطبيقات واستخدامها استنادًا إلى نموذج اتصال العميل-الخادم الخاص باستدعاء الإجراء عن بُعد (RPC). |
مجموعة قواعد تحدد تبادل البيانات المهيكلة بين العميل والخادم. |
| نهج التصميم |
تصميم موجه نحو الخدمة. يطلب العميل من الخادم تنفيذ خدمة أو وظيفة قد تؤثر أو لا تؤثر على موارد الخادم. |
تصميم موجه نحو الكيان. يطلب العميل من الخادم إنشاء الموارد أو مشاركتها أو تعديلها. |
| نموذج الاتصال |
خيارات متعددة مثل الخيار الأحادي (unary)، خادم واحد لعدة عملاء، وعميل واحد لعدة خوادم، وعدة عملاء لعدة خوادم. |
أحادي. يتصل عميل واحد بخادم واحد. |
| التنفيذ |
التنفيذ يتطلب برنامج gRPC على كل من جانب العميل وجانب الخادم. |
يمكنك تنفيذها على جانب العميل وجانب الخادم باستخدام مجموعة متنوعة من التنسيقات بدون الحاجة إلى برامج مشتركة. |
| الوصول إلى البيانات |
استدعاءات الخدمة (الوظيفة). |
يتضمن العديد من نقاط النهاية في شكل عناوين URL لتحديد الموارد. |
| البيانات التي تم استرجاعها |
في نوع الإرجاع الثابت للخدمة كما هو محدد في ملف بروتوكول التخزين المؤقت Protocol Buffer. |
في بنية ثابتة، (تكون عادةً JSON)، يحددها الخادم. |
| اقتران العميل-الخادم |
اقتران محكم. يحتاج كل من العميل والخادم إلى نفس ملف بروتوكول التخزين المؤقت Protocol Buffer الذي يحدد تنسيق البيانات. |
اقتران غير محكم. لا يكون العميل ولا الخادم على دراية بالتفاصيل الداخلية. |
| إنشاء التعليمات البرمجية تلقائيًا |
ميزة مدمجة. |
يتطلب أدوات من جهات خارجية. |
| التدفق ثنائي الاتجاه |
موجود. |
غير موجود. |
| الاستخدام الأنسب |
بنيات الخدمات المصغرة عالية الأداء أو كثيفة البيانات. |
مصادر البيانات البسيطة التي فيها تتحدد الموارد تحديدًا جيدًا. |
كيف تساعدك AWS في تلبية متطلبات gRPC وREST؟
تمتلك Amazon Web Services (AWS) مجموعةً من الخدمات والأدوات التي تساعد مصممي واجهات برمجة التطبيقات في إنشاء التطبيقات والخدمات الحديثة المستندة إلى واجهة برمجة التطبيقات وتشغيل تلك التطبيقات والخدمات وإدارتها. لمزيد من المعلومات، اقرأ حول إنشاء تطبيقات حديثة على AWS.
فيما يلي أمثلة لعروض AWS التي يمكن أن تساعدك في تلبية متطلبات واجهة برمجة التطبيقات:
- تسمح Amazon API Gateway للمطورين بإنشاء واجهات برمجة التطبيقات ونشرها وإدارتها على نطاق واسع. مع API Gateway، يُمكنك إنشاء واجهات برمجة تطبيقات RESTful API محسّنة لبنيات الخدمات المصغرة الموضوعة في حاويات وتطبيقات الويب.
- تعمل موازنة التحميل المرن (ELB) على توزيع حركة مرور الشبكة لتحسين قابلية توسّع التطبيقات. يُمكنها توجيه حركة مرور gRPC وموازنة تحميلها بين الخدمات المصغرة أو بين العملاء والخدمات الممًكّن عليها gRPC. وهذا من شأنه تحقيق انسيابية في إدارة حركة مرور gRPC في البنيات؛ بدون تغيير أي من البنية التحتية الأساسية المتعلقة بالأجهزة العميلة والخدمات الخاصة بالعملاء.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice هي خدمة شبكات تطبيقات تعمل بصفة مستمرة على توصيل الاتصالات بين خدماتك ومراقبة تلك الاتصالات وتأمينها. يُمكنك تلقائيًا توسعة نطاق موارد الحوسبة وموارد الشبكة لدعم أعباء عمل HTTP وHTTPS وgRPC ذات النطاق الترددي العالي.
ابدأ استخدام gRPC وREST على AWS عن طريق إنشاء حساب اليوم.
