ربما تكون قد سمعت كلمات مثل REST عندما يتعلق الأمر بتطوير البرامج. REST هي بنية API شائعة الاستخدام للغاية ، ويستخدمها المطورون على نطاق واسع لتصميم واجهات برمجة التطبيقات البرمجية. تعد واجهات برمجة التطبيقات أمرًا حيويًا لأي تطبيق برمجي ، و REST هي واحدة من العديد من البنى المستخدمة لواجهات برمجة التطبيقات.
في الوقت الحاضر ، تكتسب بنية g RPC شعبية ، وتزعم أيضًا أنها تحل بعض المشكلات المرتبطة تقليديًا بـ REST API s. لكن أين يختلفون؟ وأي واحد يجب أن تستخدمه لتطبيقك؟ لمعرفة الإجابة على هذه الأسئلة ، نحتاج إلى فهم المزيد حول g RPC مقابل REST وفي أي سيناريوهات تعمل بشكل أفضل. ولكن قبل أن ندخل في كل ذلك ، دعونا نلقي نظرة على ماهية واجهات برمجة التطبيقات وما تقدمه إلى طاولة الخدمات المصغرة.
ما هو API؟
يمكن أن تتفاعل تطبيقات البرامج وتتواصل مع بعضها البعض من خلال استخدام واجهات برمجة التطبيقات - واجهات برمجة التطبيقات ، التي تعمل كوسيط تقني. واجهة برمجة التطبيقات (API) هي المسؤولة عن إرسال طلب المستخدم إلى النظام ، والذي يتلقى بعد ذلك ردًا من النظام.
تخيل أنك تطلب هاتفًا عبر الإنترنت. تذهب إلى موقع مرتبط بالويب ، ويرسل معلومات حول استعلامك إلى خادم. ثم يحصل الخادم على المعلومات ويحللها ، وبعد اتخاذ الخطوات اللازمة يرد علينا بالتفاصيل المعروضة على شاشتنا. يصبح هذا ممكنًا مع واجهات برمجة التطبيقات.
توضح واجهة برمجة التطبيقات كيفية تنفيذ طلبات العميل هذه ، وهياكل البيانات التي يجب استخدامها ، والمعايير التي يجب على العملاء الالتزام بها. كما يصف أنواع الاستعلامات التي يمكن أن يرسلها أحد البرامج إلى برنامج آخر. يتم استخدام كلا نمطي البنية g RPC مقابل REST على نطاق واسع لتصميم واجهات برمجة التطبيقات.
واجهات برمجة التطبيقات والخدمات المصغرة
يمكن أن يكون للتطبيقات بنية متجانسة أو بنية خدمات مصغرة. يتم تضمين جميع وظائف ووحدات البرنامج في وحدة واحدة أو قاعدة بيانات في تطبيق موحد. في المقابل ، يتكون تطبيق الخدمات المصغرة من العديد من الوحدات الأصغر التي تتفاعل مع بعضها البعض عبر واجهات مثل بروتوكول HTTP.
تكمن المشكلة الرئيسية في الأسلوب الأحادي في أنه من الصعب تغيير النظام وتحديثه وتوسيعه حيث يقوم المهندسون بإرفاق وظائف وخدمات جديدة فوق الأساس الموجود مسبقًا. قد يكون للتغيير في أحد جوانب التطبيق تأثير ضار على الأقسام الأخرى. يصبح رمز المونوليث متشابكًا بشكل تدريجي ويصعب فهمه بعد أن يتم تحجيمه وتحديثه وتغييره عدة مرات بحيث يلزم إعادة تصميم النظام بالكامل.
تم حل هذه المشكلة من خلال الخدمات المصغرة. يقسم هذا التصميم المعماري كتلة متراصة إلى مكوناتها المكونة ، ثم يتم تشغيل كل منها كتطبيق منفصل. يُطلق على كل تطبيق من هذه التطبيقات خدمة مصغرة. بعد ذلك ، تتصل هذه الخدمات الصغيرة المميزة باستخدام واجهات برمجة التطبيقات. تأتي هذه المجموعة من الخدمات المصغرة المرتبطة بواجهات برمجة التطبيقات معًا لبناء تصميم معماري أكبر. تعمل واجهات برمجة التطبيقات على تمكين الاتصال والاتصال بين كل مكون مدمج في بنية الخدمات المصغرة. بعض الأساليب الشائعة لإنشاء واجهات برمجة التطبيقات هي GraphQL و RPC و REST.
ما هو RPC ؟
RPC - استدعاء الإجراء البعيد - هو بنية ويب تمكّنك من تنفيذ خدمة على خادم بعيد باستخدام نموذج محدد مسبقًا والحصول على استجابة بنفس التنسيق. لا يتم اعتبار نمط الخادم الذي يقوم بتنفيذ الاستعلام ، سواء كان خادمًا محليًا أو بعيدًا ، من خلال تصميم RPC.
مصدر الصورة itrelease.com/Author Junaid Rehman
الوظيفة الأساسية لطلب RPC API هي نفس وظيفة REST API. تحدد طلبات RPC API الإرشادات التفاعلية والتقنيات التي تجعل التفاعل ممكنًا. في وقت لاحق ، يستدعي المستخدم هذه الوظائف باستخدام المعلمات. تحتوي سلسلة الطلب لعناوين URL على المعلمات المستخدمة لاستدعاء العمليات.
لإنشاء طلبات API ، يستخدم نظام RPC بنية خادم العميل. يفسر RPC المعلومات التي يطلبها المستخدم وينقلها إلى الخادم. أثناء إخفاء الاتصالات الداخلية داخل الخوادم ، يستجيب الخادم للمستخدم. يتيح نموذج RPC أيضًا للمستخدم طلب خدمة بطريقة معينة. يتمتع RPC بميزة دعم استدعاءات الإجراءات عن بُعد في كل من السيناريوهات اللامركزية والمحلية.
ما هو REST ؟
REST - نقل الحالة التمثيلية - يشير إلى بنية خادم العميل حيث يمكن للمستخدمين الوصول إلى معلومات الواجهة الخلفية عبر اتصال JSON أو XML . تعتبر واجهة برمجة التطبيقات (API) مريحة إذا:
- يحتوي على واجهة متسقة ويوفر موارد تطبيقات معينة لعملاء واجهة برمجة التطبيقات.
- يعمل الخادم والعميل بشكل منفصل ومستقل. لن يعرف العميل سوى URIs التي تشير إلى مكونات التطبيق.
- إنه عديم الجنسية. هذا يعني أن العميل فقط هو الذي يحفظ أي معلومات عن الحالة. لن يقوم الخادم بحفظ أي بيانات حالة حول استعلام العميل.
- يجب أن تكون أصول التطبيق التي توفرها واجهة برمجة التطبيقات قابلة للتخزين المؤقت.
- لها بنية طبقات.
إنه تطبيق للتصميمات المعمارية المعاصرة التي تعتمد على عدة قيود للسماح بنقل البيانات في شبكات الوسائط التشعبية. تحتاج واجهة برمجة تطبيقات الويب RESTful إلى وسيطات مشفرة بعنوان URL للاتصال بالخدمات باستخدام بروتوكولات HTTP. تم تبني REST APIs على نطاق واسع في تصميم الويب المعاصر لإنشاء واجهات برمجة تطبيقات عديمة الحالة وقابلة للتوسيع ويمكن الاعتماد عليها.
يمكن عرض كل مكون يجمع نظام الخدمات المصغرة للمستخدم أو العميل كأصل عندما يتم إتاحة REST API بشكل عام. يمكن الاستعلام عن هذا المورد باستخدام أوامر HTTP GET و POST و PUT و DELETE.
كيف يعمل REST ؟
يستخدم REST بروتوكول HTTP كبروتوكول اتصال افتراضي عند العمل مع الخدمات المحددة في طلبات API. المورد هو شيء يمكن مقارنته بكائن في التصميم الموجه للكائنات. يحتوي مورد RESTful على إجراءات وسمات ، تشبه إلى حد كبير الكائن. بشكل عام ، عادةً ما تعطي تطبيقات REST أقل لإجراءات REST وتركز بدلاً من ذلك بشكل أكبر على سمات المورد. حلول RESTful هي تلك التي تستخدم السمات فقط لتمثيل مورد RESTful.
في RESTful API ، يرسل المستخدم استعلامًا إلى URL - Uniform Resource Locator ، والذي يتسبب في الرد بحمولة في JSON أو XML أو أي تنسيق بيانات مدعوم. تمثل هذه الحمولة المورد الذي يريده المستخدم. تشمل طلبات العملاء المشتركة
- طريقة HTTP تحدد ما يجب معالجته على المورد
- مسار المورد
- العنوان الذي يحتوي على بيانات حول الاستعلام
- حمولة رسالة خاصة بالعميل
في حقل قبول في الرأس ، يحدد المستخدم أنواع البيانات التي يمكنه استقبالها. يتم إرسال رأس نوع المحتوى الذي يحدد تنسيق تسليم الرسالة المستخدم في نص الاستجابة بواسطة خادم واجهة برمجة التطبيقات مع حمولة البيانات التي يسلمها إلى المستخدم الذي يقوم بالاستعلام. يتم أيضًا تضمين رمز الرد الذي يُعلم المستخدم بحالة نتيجة استدعاء واجهة برمجة التطبيقات في نص الاستجابة.
ما هو g RPC ؟
g RPC - استدعاء الإجراء البعيد من Google - هو نوع فرعي من تصميم RPC. g RPC هي بنية RPC عالمية عالية الأداء ومفتوحة المصدر تضمن المرونة والسرعة لبنية الخدمات المصغرة. يتم استخدام استدعاءات الوظائف بواسطة g RPC لضمان تفاعل العميل في الخدمات المصغرة التي تم إنشاؤها باستخدام لغات الترميز المختلفة.
تنفذ هذه التقنية طلبات RPC API باستخدام معيار HTTP 2.0 ، ولكن لا الخادم ولا مبرمج API على دراية بـ HTTP. نتيجة لذلك ، يتم تقليل التعقيد لأنه لا يوجد سبب للقلق بشأن كيفية ترجمة مبادئ RPC إلى HTTP.
يسعى Google Remote Procedure Call إلى تسريع نقل البيانات عبر الخدمات المصغرة. للسماح بالعودة والاستدعاء عن بُعد ، يعتمد على استراتيجية تحدد الخدمة ، وتؤسس المنهجيات ، وتحدد المتغيرات ذات الصلة.
بالإضافة إلى ذلك ، فإنه يستخدم لغة وصف الواجهة - IDL - لتحديد نموذج RPC API ، مما يجعل تحديد الوظائف البعيدة أسهل. يستخدم IDL المخازن المؤقتة للبروتوكول بشكل افتراضي لتعريف واجهة الخدمة وتنسيق رسائل الحمولة.
كيف يعمل g RPC ؟
يتم استخدام بروتوكول HTTP / 2 والتدفق والمخازن المؤقتة للبروتوكول أو protobufs بواسطة واجهات برمجة تطبيقات g RPC لنقل الرسائل. يسمح معيار التسلسل المسمى protobuf بالإنشاء التلقائي لمكتبات المستخدم والبناء المباشر للخدمات المصغرة. في الملفات الأولية ، يصف مصممو واجهة برمجة التطبيقات العمليات والرسائل التي يتم إرسالها عبر الخوادم والعملاء.
يقوم برنامج التحويل البرمجي protoc بتحميل الملفات وإنشاء برنامج مستخدم وخادم للتواصل مع الخدمات عن بُعد. بالمقارنة مع تنسيقات XML أو JSON ، فإن الرسائل المشفرة باستخدام مخازن البروتوكول المؤقتة أصغر بكثير ، مما يجعل المعالجة أقل كثافة في CPU.
بالإضافة إلى ذلك ، باستخدام HTTP / 2 ، تجلب واجهات برمجة تطبيقات g RPC تحسينات متنوعة على تصميم RPC. يضيف البروتوكول طبقة تنسيق ثنائية تقسم الحزم إلى رسائل أصغر ذات إطار ثنائي ، مما يجعلها قابلة للنقل وصغيرة. أصبح تنفيذ العديد من المكالمات داخل قناة واحدة ممكنًا من خلال دعم HTTP / 2 للاستعلامات المتزامنة المتعددة باستخدام بنية الاتصالات ثنائية الاتجاه.
يدعم بروتوكول النقل HTTP / 2 التدفقات المتزامنة المتعددة ، لكن واجهات برمجة تطبيقات g RPC توسع هذه الوظيفة عبر القنوات. يمكن أن تستوعب كل قناة عدة تدفقات تعمل في وقت واحد عبر العديد من الاتصالات المتزامنة. تقدم القنوات طريقة مباشرة للاتصال بخادم API على عنوان ومنفذ محددين. يمكن أيضًا عمل كعب العميل عبر القنوات.
g RPC مقابل REST: المقارنة
أنشأت Google g RPC كمتغير RPC للتعامل مع بعض قيود أنماط بنية API الحالية. إنه يحل بعض المشكلات المرتبطة بواجهات برمجة تطبيقات REST ، لكن واجهات برمجة تطبيقات g RPC تواجه بعض المشكلات نظرًا لكونها تقنية أحدث. هناك العديد من حالات الاستخدام التي قد تكون فيها واجهات برمجة تطبيقات REST أكثر ملاءمة لتطبيقك. يمكنك تحديد أي من واجهات برمجة التطبيقات هذه قد تعمل بشكل أفضل مع برنامجك بمجرد معرفة الاختلافات بين الاثنين.
HTTP 1.1 مقابل HTTP 2
يعتمد نهج الطلب والرد الذي تستخدمه واجهات برمجة تطبيقات REST بشكل أساسي على HTTP 1.1. هذا يعني أن النموذج يجب أن يعالج كل استعلام على حدة إذا تلقت الخدمة المصغرة العديد من الاستعلامات من عدة عملاء ، مما يؤدي إلى سحب النظام بأكمله إلى أسفل. يمكن تطوير واجهات برمجة تطبيقات REST على HTTP 2 ، ولكن نظرًا لأن بنية الاتصال لا تزال استجابة للطلب ، فإنها غير قادرة على الاستفادة الكاملة من مزايا HTTP 2 ، بما في ذلك التوافق ثنائي الاتجاه والتفاعل المتدفق.
لا تواجه واجهات برمجة تطبيقات g RPC هذا التحدي. إنه يلتزم بنموذج اتصال استجابة العميل ويستند إلى HTTP 2. يمكن أن يقبل g RPC العديد من الاستعلامات من عملاء مختلفين ومعالجة هذه الطلبات في نفس الوقت عبر تدفق المعلومات. تسمح هذه الظروف بالاتصال ثنائي الاتجاه مع تفاعل التدفق. بالإضافة إلى ذلك ، يدعم g RPC التفاعلات الأحادية مثل تلك التي تم إنشاؤها بواسطة HTTP 1.1.
يمكن لواجهات برمجة تطبيقات g RPC إدارة:
- التفاعلات الأحادية
إذا قدم العميل طلبًا واحدًا ، ولكن يتم تقديم رد واحد فقط في المقابل. - تدفق الخادم
يُعرف باسم تدفق الخادم عندما يجيب الخادم على استعلام العميل بدفق من الرسائل. يرسل الخادم أيضًا رسالة حالة لإنهاء الإجراء بعد توفير جميع البيانات. - تدفق العميل
يحدث هذا عندما يسلم العميل سلسلة من الرسائل ، ويستجيب الخادم برسالة واحدة. - تدفق ثنائي الاتجاه
يسمح هذا بنقل البيانات بطريقتين لأن قنوات الخادم والعميل مستقلة عن بعضها البعض.
دعم المتصفح
نظرًا لأن معظم تفاعلات واجهة برمجة تطبيقات الويب تحدث عبر الإنترنت ، فإن دعم المستعرض يعد أحد الاعتبارات الرئيسية في مناقشة g RPC مقابل REST. من المحتمل أن يكون دعم المستعرض أحد الفوائد الرئيسية لواجهات برمجة تطبيقات REST عبر g RPC. توفر جميع المتصفحات إمكانية REST API الكاملة ودعم المستعرض. ومع ذلك ، لا تزال وظيفة g RPC في المتصفحات مقيدة نسبيًا. لسوء الحظ ، تحتاج الانتقالات عبر HTTP 1.1 و HTTP 2 إلى gRPC-web بالإضافة إلى طبقة وكيل. نتيجة لذلك ، تميل واجهات برمجة تطبيقات g RPC إلى استخدامها بشكل أساسي للأنظمة الداخلية أو الخاصة ، على سبيل المثال ، في تطبيقات API المستخدمة لمعلومات الواجهة الخلفية ووظائف مؤسسات معينة.
تُستخدم التدفقات متعددة الإرسال مع بروتوكول HTTP / 2. نتيجة لذلك ، يمكن للعديد من العملاء إرسال استعلامات بشكل متوازٍ دون الحاجة إلى فتح جلسة TCP جديدة لكل واحد منهم. بالإضافة إلى ذلك ، يمكن للخادم استخدام الارتباط الموجود لتسليم الرسائل للعملاء.
يتمتع نموذج نقل الحالة التمثيلية بدعم مستعرض واسع النطاق لأنه يدمج HTTP 1.1. HTTP 1.1 ، الذي يمكّنه REST ، يستخدم طريقة مصافحة TCP لكل استعلام. غالبًا ما تواجه واجهات برمجة تطبيقات REST مشكلات زمن الوصول نتيجة لذلك نظرًا لأن المصافحة تستغرق وقتًا.
هيكل بيانات الحمولة
إذا كنا ننظر إلى بنية بيانات الحمولة أثناء النظر في g RPC مقابل REST ، فإن واجهات برمجة تطبيقات g RPC تسلسل بيانات الحمولة الصافية باستخدام مخازن البروتوكول حسب التصميم. هذه الطريقة أخف لأنها تجعل الرسائل أصغر وتسمح ببنية مضغوطة للغاية. مخازن البروتوكول في تنسيق ثنائي؛ لذلك ، لتبادل البيانات ، فإنه يقوم بترتيب المعلومات وإلغاء تسلسلها. يمكن لـ Protobuf أن يترجم تلقائيًا الرسائل المكتوبة بشدة إلى لغات برمجة العميل والخادم.
ومع ذلك ، يستخدم REST في الغالب نماذج JSON أو XML لتقديم المعلومات وتلقيها. JSON هو الشكل الأكثر استخدامًا نظرًا لقدرته على التكيف وقدرته على توصيل البيانات الديناميكية دون التقيد بهيكل دقيق ، على الرغم من أنه لا يتطلب أيًا. تعد جودة قابلية القراءة البشرية لـ JSON ، والتي لا تستطيع Protobuf مطابقتها بعد ، ميزة مهمة أخرى.
ومع ذلك ، فإن JSON ليست سريعة أو خفيفة الوزن بمجرد أن تتضمن نقل البيانات. ويرجع ذلك إلى الحاجة إلى تسلسل JSON وترجمته إلى لغات البرمجة المستخدمة في كل من الخادم ونهاية العميل عند استخدام REST. هذه خطوة إضافية في عملية نقل البيانات ، والتي يمكن أن تضر بالكفاءة وتزيد من احتمال حدوث أخطاء.
رمز الجيل
يجب على المهندسين استخدام أدوات الجهات الخارجية مثل Postman لتوليد الكود لاستعلامات واجهة برمجة التطبيقات منذ ذلك الحين ، وعلى عكس g RPC ، تفتقر REST API إلى مرافق إنشاء التعليمات البرمجية المضمنة. على عكس ذلك ، يوفر g RPC ميزات إنشاء التعليمات البرمجية الأصلية بسبب مترجم protoc الخاص به ، والذي يدعم العديد من لغات البرمجة. يعد إنشاء الكود مفيدًا بشكل خاص للخدمات المصغرة التي تجمع بين العديد من الخدمات التي تم إنشاؤها على منصات ولغات متعددة. بشكل عام ، فإن إنشاء الكود المدمج به يجعل إنشاء مجموعة تطوير البرامج - SDK - أسهل.
من ناحية أخرى ، لا توفر واجهة برمجة تطبيقات REST ميزات إنشاء التعليمات البرمجية الأصلية. يجب عليك استخدام برنامج تابع لجهة خارجية لإنتاج إنشاء رمز لمكالمات API بعدة لغات. على الرغم من أنها ليست مشكلة ، إلا أنه من المهم ملاحظة أن g RPC لا تعتمد على أي خدمات أخرى لإنشاء الكود.
متى تستخدم واجهات برمجة تطبيقات REST
عند مقارنة g RPC مقابل REST ، فإن واجهات برمجة التطبيقات (API) الأكثر استخدامًا والأكثر شهرة لدمج البنى التحتية المبنية على الخدمات الصغيرة هي واجهات برمجة تطبيقات REST. من المحتمل أن تستمر واجهات برمجة تطبيقات REST في كونها الخيار الافتراضي لاتصال التطبيق لفترة طويلة جدًا ، بغض النظر عما إذا كنت تنشئ شبكة داخلية أو نظامًا أساسيًا مفتوحًا يفتح أصوله لبقية العالم. تعد واجهات برمجة تطبيقات REST أيضًا مثالية للأنظمة التي تتطلب التكرار السريع ومعايير بروتوكول HTTP.
يمكن أن تكون واجهات برمجة تطبيقات REST هي خيارك الأول لتطوير خدمات الويب والخدمات المصغرة وواجهات التطبيقات لأن تقنيات الجهات الخارجية تدعمها عالميًا. بخلاف g RPC ، يتمتع بدعم متصفح واسع ولا يقتصر على الأنظمة الخاصة. هذا يمكن أن يجعل REST APIs مفيدة للغاية في العديد من السياقات.
من الأسهل أيضًا تعلم REST ، حيث يحتوي على مجموعة واسعة من وثائق API المتاحة على الإنترنت. يعد منحنى التعلم الأبسط هذا مهمًا جدًا إذا كنت في أزمة زمنية. يمكنك توفير الكثير من الوقت في البحث والتعلم والبدء في التنفيذ على الفور. RESTful API هي أيضًا أسهل في الاندماج في التطبيقات. كما أنها توفر قابلية تطوير أفضل. إذا كنت ترغب في توسيع تطبيقك قريبًا ، فقد يكون من الأفضل استخدام واجهات برمجة تطبيقات REST. يمكن أن يتسبب الافتقار إلى الحالة والسرية في حدوث مشكلات مع نقل الحالة التمثيلية في بعض التطبيقات. إذا كان التطبيق الخاص بك يحتوي على خيار دفع ، فقد يكون g RPC خيارًا أفضل.
متى تستخدم واجهات برمجة تطبيقات g RPC
في كل من g RPC مقابل REST ، لا تزال غالبية أدوات الجهات الخارجية لا توفر وظائف مضمنة لتوافق g RPC. نتيجة لذلك ، تُستخدم واجهات برمجة تطبيقات g RPC في الغالب لإنشاء أنظمة أو هياكل داخلية لا يمكن الوصول إليها من قبل المستخدمين الخارجيين. مع وضع هذا التأهيل في الاعتبار ، يمكن أن تستفيد المواقف التالية من واجهات برمجة تطبيقات g RPC:
- اتصالات الخدمات المصغرة
تعد واجهات برمجة تطبيقات g RPC مفيدة بشكل خاص لربط البنى المكونة من خدمات صغيرة خفيفة حيث تكون فعالية تسليم الرسائل أمرًا بالغ الأهمية نظرًا لانخفاض زمن الوصول والاتصال السريع بالنطاق الترددي.
- أنظمة متعددة اللغات
تتفوق g RPC في التعامل مع الاتصالات في سياق متعدد اللغات بفضل قدرتها على إنشاء الكود الأصلي لمجموعة واسعة من لغات البرمجة.
- دفق في الوقت الحقيقي
إذا كان الاتصال في الوقت الفعلي ضروريًا ، يمكن للنظام الخاص بك إرسال واستقبال البيانات في الوقت الفعلي دون الحاجة إلى انتظار تفاعل Unary مع العميل بفضل قدرة gRPC على التعامل مع التدفق ثنائي الاتجاه.
- شبكات منخفضة الطاقة وعرض النطاق الترددي المنخفض
يمكن أن تستفيد هذه الشبكات من استخدام gRPC لجلسات Protobuf المتسلسلة نظرًا لأنها توفر اتصالًا خفيف الوزن وكفاءة محسّنة وسرعة. على سبيل المثال ، الشبكة التي ستستفيد من g RPC API هي إنترنت الأشياء.
كيف يساعد AppMaster ؟
لقد تغيرت البرمجة كثيرًا في العقود الأخيرة ، مع وجود تقنيات وأطر عمل جديدة تجعل مهام المطورين أسهل. No-code يأخذ هذا إلى المستوى التالي. لا يتعين على الأشخاص المرور عبر منحنيات التعلم الحادة ويمكنهم تطوير التطبيقات بشكل أسرع باستخدام الأنظمة الأساسية no-code مثل AppMaster.
يساعدك AppMaster إنشاء كود المصدر من البداية وفقًا للاحتياجات المحددة لتطبيقك. سيكون الرمز الذي تم إنشاؤه ملكًا لك ، ويمكنك تعديله وفقًا لاحتياجاتك. يمكنك إنشاء الوحدات النمطية المختلفة التي يحتاجها تطبيقك باستخدام AppMaster. هذا أقل تكلفة بكثير ويستغرق وقتًا طويلاً من جعل فريق التطوير بأكمله يفعل الشيء نفسه.
يمكن للمطورين إرسال استعلامات بين بنية الخدمات المصغرة الخلفية باستخدام بروتوكول g RPC باستخدام منصة توليد no-code في AppMaster. سنضيف واجهة برمجة التطبيقات (API) إلى كل من تطوير خدمات الويب لـ g RPC وكذلك تطبيقات الجوال g RPC في العام التالي لزيادة دعم g RPC.
استنتاج
كان النقل التمثيلي للدولة هو النهج الذي تم الانتقال إليه عندما يتعلق الأمر بتطوير API في الماضي. ولكن بين g RPC مقابل REST ، أصبحت واجهات برمجة تطبيقات g RPC أكثر شيوعًا ببطء. على الرغم من الميزات المتنوعة التي تجعله مميزًا ، إلا أن بعض المشكلات ، مثل نقص دعم المتصفح ووثائق واجهة برمجة التطبيقات ، تجعل من الصعب استخدامه في كل مكان. ومع ذلك ، مع التقدم التكنولوجي ونمو المجتمع ، يمكننا أن نأمل أن يتغلب g RPC على تحديات اليوم.
أخيرًا ، يعتمد الاختيار بين REST أو g RPC ، أو حتى أي من منهجيات API الأخرى مثل GraphQL أو SOAP ، على الاحتياجات المحددة لمشروعك. قد تحتاج بعض التطبيقات إلى المزايا التي يوفرها g RPC ، بينما قد يتطلب البعض الآخر الوظائف الأساسية التي يوفرها REST. تحتاج إلى تقييم وظائف التطبيق الخاص بك وحالات الاستخدام للاختيار بين هاتين التقنيتين القادرة.
