تقسم الهيكل الشعبي للعميل والخادم الاتصال إلى جزئين: الجزء الأول الذي يتولى جميع المهام الثقيلة ويقدم الخدمات، والمعروف باسم الخادم، والجزء الآخر الذي يستمتع بتلك الخدمات، والمعروف باسم العميل.
بشكل عام في اتصال العميل والخادم، يرسل العميل طلباً يطلب فيه الموارد أو الخدمات إلى الخادم، ويستجيب الخادم لذلك الطلب.
للتواصل بين العملاء والخوادم، يحتاج العميل والخادم إلى مكتبات يمكنها فهم البروتوكول الذي يتواصلون به. البروتوكول هو لغة أو مجموعة من قواعد الاتصال عبر الإنترنت. إنها آليات نقل تتبع بعض الإرشادات لنقل البيانات عبر الإنترنت.
الجانب الثاني الأهم في الاتصال العميلي هو تنسيق الرسالة الذي يمكن لكل من العميل والخادم الموافقة عليه. يعتمد هذا التنسيق الرسائل على بعض المخططات، وعدم اتباع هذه المخططات لن يحدث الاتصال. يمكن أن يكون تنسيق الرسائل مشابهًا لـ XML، الذي يلتزم بمخطط، أو ملف JSON، الذي يجب أن يحتوي على أزواج قيمة محددة.
من الجوانب المهمة في هذا النوع من الاتصال لفهمه أنه يعتمد على آلية طلب واستجابة، مما يعني أن الخادم يتواصل فقط عندما يبدأ العميل في الاتصال. مع REST و GraphQL، هذا في الغالب أحادي الاتجاه. هذه مشكلة أساسية ستحلها تقنيات مثل gRPC.
لماذا ظهر REST؟
في أوائل التسعينيات، كان هناك بروتوكول شعبي يعتمد على العميل والخادم يسمى SOAP الذي استخدم تنسيق الرسائل XML بنموذج معياري ثابت. كان النموذج المعياري لتنسيق الرسائل قاسيًا للغاية. نقص الحرية هو ما أدى إلى التخلي عن SOAP وظهور REST.
جاء REST إلى الوجود بسبب ازدياد شعبية JavaScript، مما أدى إلى زيادة شعبية تنسيق ملف JSON. كان من السهل فهمه وكان مريحًا. كان في تنسيق رسالته ببساطة أزواج من المفتاح والقيمة.
بكلمات بسيطة، Rest هي دليل لنقل رسائل JSON عبر الإنترنت باستخدام HTTP كبروتوكول (وسيط نقل). مع Rest، لا يحتاج المرء إلى القلق بشأن إعداد نموذج معياري.
ما هو REST؟
تحدثنا عن ظهور REST. الآن دعونا نغوص في تكنولوجياته الأساسية. لذا دعوني أخبركم أن REST تعني نقل الحالة التمثيلية. Rest هي أسلوب مؤثر معياري للبرمجيات، وهي API مستخدم كثيرًا في الصناعة.
أسباب شعبية واستخدام كبير لـ REST
- REST بسيط ومعياري لبنية الاتصال. عند استخدام R، لن تضطر إلى القلق بشأن تنسيق رسالتك أو بياناتك. لا داعي للقلق بشأن تنسيق رسالتك في كل مرة، حيث يتم توفير كل شيء بشكل معياري ومستخدم في الصناعة.
- REST قابل للتوسعة. إذا أصبحت خدمتك أكبر وتحتاج إلى المزيد من الوظائف، يمكنك بسهولة تجديد خادمك دون القلق بشأن أداء REST من الخادم، ويمكنك إنشاء وظائف جديدة بشكل منفصل ما لم تفسد بياناتك.
- REST هو عدم تماسك. وهذا يعني أن كل طلب سيحمل بعض البيانات التي يجب أن يفهمها الخادم. يساعدت بنية الخادم على تذكر معلومات هذا الطلب، ولكن في بنية REST، يتم تخزين حالة الجلسة على الجانب العميل، مما يجعل الخادم أكثر كفاءة ويقلل العبء عند العمل بدقة أكبر.
- أخيرًا وليس آخرًا، Rest هي بنية عالية الأداء وتدعم التخزين المؤقت.
متى يفضل استخدام REST
تخيل أنك تقوم بإنشاء موقع ويب لمطعم. لديك كل القوائم على الإنترنت، والعناصر الغذائية مقسمة إلى ثلاث فئات:
- الأطباق الإفطارية
- الوجبات الرئيسية
- المشروبات
الآن، لنفترض أنك تريد رؤية كل المشروبات على الإنترنت. في بنية Rest، يمكنك بسهولة وبتنظيم متسق تقسيم جميع مواردك على نقاط نهاية API. بالطبع، يمكنك استخدام توثيق متعدد عليها لجعلها آمنة.
في هذا النوع من الحالات، نرسل طلب GET إلى الخادم إلى نقطة نهاية حيث يمكننا الحصول على بيانات مورد المشروبات.
وبالمثل، يمكننا إجراء جميع عمليات CRUD (إنشاء، قراءة، تحديث، حذف) في API Rest، مما يجعلها مناسبة للمشاريع الكبيرة التي لا تتطلب نقل للبيانات بشكل فائق ولا تحتاج إلى التواجد الفوري.
Rest يعمل بشكل مثالي للمشاريع حيث يكون نقل البيانات بكفاءة مهمًا. التخزين المؤقت هو ميزة أخرى لـ REST تكون مفيدة للتطبيقات القياسية مثل تطبيقات حجز الطعام، تطبيقات حجز الفنادق، مواقع المدونات، مواقع المنتديات على الإنترنت، إلخ.
العيوب والمشاكل مع REST
REST ممتاز، لكنه يتسبب في العديد من العيوب الحرجة في بعض الحالات. دعونا نتحدث عنها.
- الحاجة إلى الاتصال الثنائي الاتجاه.
ماذا لو احتج الخادم لإرسال بعض البيانات إلى العميل؟ الخادم الذي يرغب في بدء الاتصال. في بنية REST، هذا غير ممكن. بالطبع، يمكنك استخدام بعض الحيل، لكنها ليست عملية. - تخيل إنشاء موقع للنتائج الحية. كيف ستتحكم في إرسال طلب من الخادم إلى العميل لتحديث بيانات النتيجة؟ يمكننا جعل العملاء يرسلون طلبات كل 10 ثوان، لكنها ليست ممارسة جيدة على الإطلاق. سيؤدي ذلك إلى تعرض الخادم للإرهاق، مما قد يؤدي إلى مشاكل في السرعة.
- بنية REST تعتبر مطلقة الطلب والاستجابة ولا تدعم تدفق البيانات (المعالجة المستمرة للأحداث).
- خاصية REST بأن تكون غير متخزنة قد تعتبر نعمة ولعنة في آن واحد لأنك لا يمكنك تحديد حالة البيانات في بنية REST.
لماذا جاءت gRPC إلى الوجود؟
لمعالجة المشكلة الأولى مع REST، وهي الحاجة إلى الاتصال الثنائي الاتجاه، تم اختراع WebSocket، الذي يسمح للخادم ببدء الاتصال، لكن المشكلة معه هي أنه لا يملك تنسيقًا. هو فقط يرسل بايتات وليس لديه قيود.
لم تكن لدى Websockets مشاكلها الخاصة، لكن القضية الحقيقية هي أن أي نوع من الاتصال يحتاج إلى بروتوكول، وكل بروتوكول يحتاج إلى مكتبة عميل قادرة على التواصل باستخدام هذا البروتوكول.
إذا كنت تقوم بإنشاء تطبيق Python يعمل على بنية الـ Rest، ستحتاج إلى عميل HTTP يمكنه التواصل مع الخادم. في كثير من الأحيان، تتم إنشاء مكتبات العميل من قبل طرف ثالث، وغالباً ما يكون مطور مستقل. استخدام مكتبات الطرف الثالث يمكن أن يعرض أمانك، وسيعتمد تطبيقك بأكمله على طرف ثالث للتواصل.
في حالة التطبيقات الويب، يعمل المتصفح كمكتبة عميل، ولكن بالنسبة للمشاريع غير الويب، ستحتاج إلى مكتبة عميل طرف ثالث. إذا كنت تفكر في إنشاء واحدة بنفسك، فتذكر أنه ليس بتلك السهولة، وستضطر إلى الحفاظ على تطبيق آخر.
لذا، لمعالجة بعض مشاكل الـ Rest ولمعالجة مشاكل مكتبات العميل، اخترعت Google gRPC في عام 2015.
بالنسبة لـ gRPC، يتم الحفاظ على مكتبة عميل واحدة من قبل Google لجميع اللغات الشهيرة تقريباً. يستخدم البروتوكول HTTP 2 تحت غطاء ومحرك البروتوكول (protobuf) كتنسيق رسائله.
لا داعي للقلق بشأن مكتبة عميل أي، لأن Google تحتفظ بها من أجلك ولجميع لغات البرمجة تقريباً. مكتبة عميل واحدة ومركزية هي إحدى القوى الرئيسية لـ gRPC.
فائدة أخرى من gRPC هو تنسيق الرسائل التي يستخدمها. محرك البروتوكول غير مرتبط بأي لغة، لذا يمكنك إنشاء عملاء في Python وخوادم في Go ولا يزال بإمكانك التواصل دون القلق.
gRPC هو في الأساس مكتبة عميل واحدة وبروتوكول واحد يمكن استخدامه على أي جهاز.
ما هو gRPC؟
gRPC يستخدم protobuf للتواصل. يقوم بتحويل ملفات proto إلى تنسيق ثنائي ويرسلها إلى الخادم، وعلى الجانب الخادمي، يتم تحليلها إلى الشكل الأصلي. هكذا يعمل مع protobuf.
gRPC لديه أشكال تواصل مختلفة. يمكنك التفكير فيها كميزات gRPC.
ميزات gRPC
- طلب واحد: إنه نوع بسيط من الاتصال الطلب والاستجابة التي يرسل فيها العميل طلب proto وبعد تلقيه، ينتظر الخادم بعض الوقت لأداء بعض العمليات ثم يعيد بعض الاستجابات.
- تيار الخادم: بعد إرسال طلب واحد، يأتي تيار من البيانات كاستجابة من الخادم. على سبيل المثال، عند النقر على مقطع فيديو، يغادر الكثير من بيانات الفيديو الخادم.
- تيار العميل: إنه عكس تيار الخادم. هنا يرسل العميل الكثير من البيانات في آن واحد إلى الخادم. على سبيل المثال، يحدث ذلك عندما تشارك ملفًا كبيرًا على الإنترنت أو ترفع صورة أو فيديو على الإنترنت. يرسل العميل باستمرار بيانات إلى الجانب الخادمي.
- التيار الثنائي: في هذا النوع من الاتصال، يرسل العميل والخادم رسائل متعددة. الدردشة مثال رائع على ذلك.
هذه أربعة ميزات شهيرة في gRPC تجعله قويًا جدًا.
متى يفضل استخدام gRPC
بالنسبة لميزات gRPC، رأينا بعض الاستخدامات لـ gRPC. لنتخيل أنك تريد إنشاء تطبيق محادثة. لن تستخدم API الأسترجاعي لأنه لن يكون قادرًا على السماح ببث سريع للاتصالات ثنائية الاتجاه. لهذا، سنستخدم تيار gRPC، الذي سيوفر بعض المزايا الإضافية إلى السرعة.
أولاً، سلوكه المحايد بين اللغات لا يهم بأي لغة البرمجة يتم كتابة الخادم أو العملاء الآخرين. لا يزال من الممكن إنشاء الاتصال طالما تم قبول تنسيق الرسالة.
لذا، بهذه الميزة، يمكن لإصدار Android من تطبيق المحادثة التواصل مع إصدار iOS والعكس بالعكس.
مشاكل مع gRPC
هناك قضايا مع كل شيء، بما في ذلك gRPC.
- الدعم المحدود للمتصفحات:gRPC يستخدم HTTP 2، لذا من الصعب استدعاء خدمة gRPC مباشرة من المتصفح. مما يتطلب أحيانًا إعداد عميل.
- شكل غير قابل للقراءة:كما نعلم جميعًا، يستخدم gRPC تنسيقًا ثنائيًا لا يمكن قراءته من قبل البشر. إنه عيب في بعض الحالات.
- نقص النضوج:تم تطوير gRPC في عام 2015، لذا لا يزال غير ناضج بعض الشيء مقارنة بـ REST، وهناك العديد من البقايا والمشاكل التي يجب حلها.
- مشاكل التعلم:يستخدم Rest و GraphQL JSON، وهو أسهل للتعلم. معظم الناس سيحاولون التمسك بهما لأن protobuf لا يزال موضوعًا جديدًا ومعقدًا، لذا سيكون من الصعب العثور على خبراء gRPC.
REST مقابل gRPC:
الآن سنناقش الفرق التقني بين REST وgRPC.
تنسيق الرسالة:
يستخدم تنسيق الرسالة في REST في الغالب JSON (وفي بعض الأحيان تنسيق XML)، وهو شكل قابل للقراءة أكثر وأسهل في المعالجة. لن تقلق بشأن الشيمات في Rest. من ناحية أخرى، يستخدم gRPC بروتوكول بافو الترابط لتحويل البيانات إلى تنسيق ثنائي، مما يجعل النموذج المضغوط أخف وأسرع في التنقل.
HTTP 1.1 مقابل HTTP 2:
عادةً ما يستخدم واجهة برمجة تطبيقات Rest HTTP 1.1 كبروتوكولها، بينما يستخدم gRPC HTTP 2 كبروتوكول تحت غطاء مكابح. يمكن لواجهة برمجة تطبيقات Rest استخدام HTTP 2 ولكنها لا تزال محدودة نتيجة لآلية الطلب والاستجابة. يستفيد gRPC من دعم HTTP 2 لكل من الاتصالات الاستجابة للعميل والاتصالات الثنائية. هذا جانب آخر يجعل أداء gRPC أفضل من REST. يمكنه إدارة الطلبات غير الثنائية مثل HTTP 1.1 والطلبات الثنائية في وقت واحد مثل HTTP 2.
اللافتة:
سرعة gRPC المنخفضة في الاتصال والسرعة العالية تجعله مفيدًا للاتصال بأنظمة تتكون من نظام ميكرو خدمات خفيف الوزن، مما يزيد من كفاءة تدفق الرسائل. في معظم حالات الشبكة، يستغرق REST 25 ميلي ثانية، بينما يكون تأخير gRPC أقل بكثير من REST.
الحد الأقصى لحمل الرسالة:
لدى Rest حد أقصى لحمل الرسائل يبلغ 45 ميغابايت عند إرسال الرسائل الخارجية، بينما لا يوجد لدى gRPC أي حد، مما يعني أن حجم رسالتك الخارجية يمكن أن يكون ثقيلًا بقدر ما تريد.
الأمان:
فيما يتعلق بالأمان، ستكون Rest أبطأ لأنها تستخدم HTTP 1.1 وصيغة JSON، التي يسهل فك تشفيرها والوصول إليها. من ناحية أخرى، تستخدم gRPC HTTP 2، وهو أكثر أمانًا، وتستخدم protobuf، وهو بتنظيم ثنائي ويصعب فك تشفيره.
السرعة:
مرة أخرى، يفوز gRPC، حيث توفر سرعة تزيد عن عشرة أضعاف مقارنة بـ Rest، وذلك لنفس السبب، استخدام HTTP 2 كبروتوكول وprotobuf كصيغة الرسالة.
وظيفة توليد الكود
Rest لا توفر ميزات توليد الكود مدمجة، مما يعني أن المطور بحاجة إلى تطبيقات ثالثة لإنتاج رموز API، بينما تمتلك gRPC ميزات توليد الكود المبنية فيها بسبب مُترجم protobuf الخاص بها، وهو متوافق مع عدة لغات البرمجة. هذا فوز آخر، خاصة بالنسبة لتصاميم الخدمات الدقيقة.
بوابة Memphis REST
لتمكين إنتاج الرسائل عبر مكالمات HTTP لأغراض مختلفة وسهولة الاستخدام، أضافت مدينة Memphis بوابة HTTP لاستقبال طلبات قاعدة Rest وإنتاج تلك الرسائل إلى المحطة المطلوبة.
الاستخدامات الشائعة التي تستفيد من بوابة REST هي:
- إنتاج الأحداث مباشرة من الواجهة الأمامية
- ربط Debezium باستخدام خادم HTTP
- روابط ArgoCD
- تكامل PostHog
- استقبال بيانات من Fivetran/Rivery/أي منصة ETL باستخدام مكالمات HTTP
بوابة Memphis REST + مخطط JSON يمكن أن يكون مزيجًا قويًا لزيادة جودة البيانات وضمان التواصل الصحيح بين التطبيقات أو الخدمات.
سيدعم Memphis قريبًا gRPC أيضًا.
نتيجة
في النهاية، أود أن أقول إن REST لا يزال الهيكل الأكثر استخدامًا وشهرة ومن المستحيل التخلي عنه. يتضمن REST العديد من العيوب، مثل عدم وجود تدفق بيانات، عدم التواصل الثنائي الاتجاه، سرعة بطيئة، إلخ، لكنه يعد الأفضل للتطبيقات القياسية التي نراها في الحياة اليومية.
من ناحية أخرى، gRPC، وهو شاب وصعب التعلم، يوفر العديد من الأشياء مثل تدفق بيانات عالي على كل من جانب العميل والخادم، تدفق بيانات ثنائي الاتجاه جيد، سريع ومكثف، ويستخدم HTTP 2. بسبب أدائه السريع، يعد gRPC الأنسب للتطبيقات ذات العبء العالي مثل تدفق الفيديو، تدفق الأغاني، الألعاب عبر الإنترنت، مشاركة الملفات، وتطبيقات الدردشة.