Editor’s Note: The following is an article written for and published in DZone’s 2024 Trend Report, إدارة الواجهات البرمجية الحديثة: توصيل الهياكل القائمة على البيانات مع الذكاء الاصطناعي والأتمتة والوحدات النمطية.
تلعب الواجهات البرمجية (APIs) دوراً حاسماً في عالم تطوير البرمجيات الحديث. يمكن استخدام أنواع متعددة من الواجهات البرمجية لتأسيس الاتصال وتبادل البيانات بين الأنظمة المختلفة. يقف في المقدمة توجه REST، الذي سيطر على الصناعة بسبب بساطته وقابليته للتوسع. ومع ذلك، مع تطور التكنولوجيا، تغيرت طلبات المطورين والشركات أيضاً. في السنوات الأخيرة، ظهرت بدائل مثل GraphQL والواجهات البرمجية القائمة على الأحداث المتزامنة التي تقدم مزايا متميزة على الواجهات البرمجية REST التقليدية.
في هذا المقال، سنلقي نظرة على كل من تقنيات الواجهات البرمجية هذه ونبني فهم تبايني بينها.
REST: بداية الاتصال الموجه للموارد
يتمحور نظام البناء REST حول مفهوم الموارد. تلك هي الكيانات التي يمكن إدارتها عبر طرق HTTP القياسية مثل GET و POST و PUT و DELETE. إحدى الخصائص الرئيسية لـ REST هي طبيعتها غير الموضوعة، حيث يحتوي كل طلب من العميل على جميع المعلومات اللازمة لخدمة الخادم له. يفصل هذا العميل والخادم، مما يسمح لهما بالتوسع بشكل مستقل.
الإيجابيات والسلبيات في REST
تتمتع واجهات برمجة REST ببعض الإيجابيات الكبيرة:
- يتبع REST تصميمًا بسيطًا واستقلابيًا مبنيًا على طرق HTTP القياسية.
- كل طلب في منهجية REST مستقل، مما يؤدي إلى تحسين التوسعة والموثوقية.
- يستخدم REST آليات الخزن في HTTP لتحسين الأداء وتقليل الحمل على الخادم الأصلي.
- REST متوافق، ويعمل بشكل جيد مع لغات البرمجة والمنصات المختلفة بفضل تنسيقه القياسي.
ومع ذلك، تحتوي الهيكلية الخاصة بـ REST على عدة عيوب:
- يمكن أن تؤدي واجهات برمجة التطبيقات REST إلى الجذر الزائد، حيث يتلقى العملاء بيانات أكبر من اللازمة، مما يؤدي إلى تعمق الكفاءة وتبديد السعة الشبكية.
- مما يشابه النقطة الأولى، يمكن أن تعاني واجهات برمجة التطبيقات REST أيضًا من الجذر المنخفض، حيث يلزم عدة طلبات لتلبية متطلبات بيانات معقدة. مما يؤدي إلى زيادة التأخير.
- يتبع REST منهجية متزامنة يمكن أن تؤدي إلى الحجب ومشاكل الأداء في سيناريوهات الحمل العالي.
- التغييرات في مخطط البيانات للواجهة يمكن أن تؤثر على العملاء، مما يؤدي إلى التثبط الصارم.
استخدام حالات واجهات برمجة التطبيقات REST
هناك حالات افتراضية حيث تكون واجهات برمجة التطبيقات REST أكثر تناسبًا مقارنة بأنواع أخرى من الواجهات، على سبيل المثال:
- التطبيقات الكثيفة في الخزن – تطبيق يتضمن الكثير من القراءة مثل مواقع الأخبار أو المحتوى الثابت، يمكن أن يستفيد من آلية الخزن في REST. توجيهات الخزن المقياسية لـ REST تجعلها أسهل للتنفيذ.
- العمليات البسيطة للCRUD – عند التعامل مع عمليات CRUD البسيطة، توفر واجهات برمجة التطبيقات REST بساطة وقابلية التوقع. غالباً ما تجد التطبيقات ذات نموذج بيانات واضح وثابت أن واجهات برمجة التطبيقات REST أكثر ملاءمة.
GraphQL: ظهور التحضير الإعلاني للبيانات مع واجهات برمجة التطبيقات
GraphQL هو مزيج من لغة فصل المصادر المفتوحة لاستعلام البيانات وكذلك وقت التشغيل لتحقيق تلك الاستعلامات. المبدأ الأساسي وراء GraphQL هو وجود بنية شاملة لتعريف استعلامات البيانات، مما يسمح للعملاء بتحديد البيانات التي يحتاجونها بالضبط في طلب واحد.
الشكل 1. GraphQL في الصورة الكبيرة
من عدة جوانب، كانت GraphQL ردّاً مباشراً على مشاكل الهيكل التقليدي لواجهة برمجة التطبيقات REST.
ومع ذلك، فإنها تعزز الهيكل المكتوب بقوة، مما يوفر للمطورين فكرة واضحة عما يمكن توقعه. تدعم GraphQL تحديثات البيانات في الوقت الفعلي من خلال الاشتراكات. على مر السنين، حدث الكثير من العمل على أدوات مثل GraphQL Federation لجعل واجهات برمجة التطبيقات GraphQL أكثر قابلية للتوسع للشركات الكبيرة ذات المجالات المتعددة.
المزايا والعيوب في GraphQL
يوفر GraphQL بعض المزايا الرئيسية:
- مع GraphQL، يمكن للعملاء طلب البيانات المحددة التي يحتاجونها فقط. هذا يلغي مشاكل التجاوز والنقص في الاستيراد مع واجهات برمجة التطبيقات REST.
- منهجية الهيكل المكتوب بقوة في GraphQL توفر بنية واضحة والتحقق من الشروط، مما يسرع التطوير والوثائق.
- تعمل GraphQL عادة عبر نقطة واحدة. يحتاج العملاء فقط إلى الاهتمام بنقطة واحدة أثناء التحدث إلى خادم GraphQL حتى لو كان هناك مصادر متعددة للبيانات.
- تتضمن الاستبطان الذاتي للعملاء استكشاف المخطط واكتشاف البيانات والعمليات المتاحة.
هناك أيضًا عدد من العيوب في GraphQL:
- تنفيذ GraphQL يتطلب جهدًا إضافيًا وخبرة عند مقارنته بواجهات برمجة التطبيقات (APIs) التقليدية REST.
- نظرًا للمرونة التي تتمتع بها الاستعلامات في GraphQL، يمكن أن تكون تخزين البيانات صعبة التطبيق وقد تحتاج إلى حلول مخصصة.
- بينما تقلل GraphQL من الحصول على الكثير من البيانات في المستوى العلوي، يمكن أن تؤدي الاستعلامات المتداخلة إلى استلام بيانات غير ضرورية.
- الملكية لطبقة GraphQL المشتركة تصبح مربكة، على عكس الحدود الواضحة لواجهة برمجة التطبيقات REST.
استخدامات GraphQL
هناك مواقف محددة تقوم فيها GraphQL بعمل أفضل مقارنة بواجهات برمجة التطبيقات REST، مثلا:
- متطلبات البيانات المعقدة والمتداخلة – لجلب البيانات ذات العلاقات المعقدة، يساعد GraphQL العملاء على تحديد البيانات التي يحتاجون إليها بدقة في استعلام واحد.
- تحديثات البيانات في الوقت الفعلي – تساعد اشتراكات GraphQL التطبيقات على التعامل مع تحديثات البيانات في الوقت الفعلي مثل تطبيقات الدردشة أو اللوحات المباشرة. مع GraphQL، يمكن للعملاء الاشتراك في تغيرات البيانات المحددة، مما يسمح بتحديثات في الوقت الفعلي دون الحاجة إلى التصفيح المتكرر.
- تصاميم الخدمات الدقيقة – في هذه الحالة، يتم توزيع البيانات عبر خدمات متعددة. يوفر GraphQL واجهة موحدة للعملاء لطلب البيانات من خدمات مختلفة. لا يتعين على تطبيق العميل إدارة مخططات REST متعددة.
واجهات API غير المتزامنة: تحول إلى تصميم يعتمد على الأحداث
على مر السنين، الدفع للتبني أو الترحيل إلى تصميم يعتمد على الأحداث في البنية التحتية المستندة إلى الغيل أيضاً أدى إلى ظهور البنيات التحتية المستندة إلى الأحداث، حيث يكمن الميزة في احتمال التواصل غير المتوقف بين المكونات. مع واجهات API غير المتزامنة، لا يحتاج العملاء للانتظار حتى يستجيبوا قبل المتابعة في عملية التنفيذ. يمكنهم إرسال الطلبات ومتابعة عملية التنفيذ. يعد هذا النهج مفيدًا للسيناريوهات التي تتطلب تزايد متزامن كبير وقابلية التوسع والاستجابة الفعالة.
في الأنظمة المستندة إلى الأحداث، تتعامل واجهات API غير المتزامنة مع الأحداث والرسائل مع المساعدة من تقنيات مثل أباتشي كافكا و رابيتمق، التي توفر وسيلة للتواصل بين منتج الرسائل والمستهلك.
بالنظر إلى نظام نموذجي يستخدم نهج API مستند إلى الأحداث، لدينا منتجون ينشرون الأحداث إلى المواضع، ويشترك المستهلكون في هذه المواضع لتلقي ومعالجة الأحداث بشكل غير متزامن. هذا يسمح بالقابلية السلسة للتوسع وحماية الخطأ لأنه يمكن لكل من المنتج والمستهلك التطور بشكل مستقل. الرسم التوضيحي التالي يوضح مثل هذا النظام:
الشكل 2. نظام مستند إلى الأحداث مع كافكا وواجهات API غير المتزامنة
مزايا وعيوب واجهات البرمجة المتماثلة اللاسيكلونية
هناك بعض المزايا الرئيسية لواجهات البرمجة المتماثلة اللاسيكلونية:
- تكون واجهات البرمجة المتماثلة اللاسيكلونية مناسبة للتعامل مع الحجم العالي للتزامن ومتطلبات القابلية للتوسع لأنه يمكن التعامل مع عدة طلبات بشكل متوازي.
- تمكن واجهات البرمجة المتماثلة اللاسيكلونية أيضًا من معالجة البيانات في الوقت الحقيقي عن طريق تمكين الاستجابة في الوقت المناسب للأحداث.
- يمكن أن تساعد واجهات البرمجة المتماثلة اللاسيكلونية أيضًا في استخدام أفضل لموارد النظام عن طريق تحويل المهام إلى عمليات في الخلفية.
- وأخيرًا، تزيد واجهات البرمجة المتماثلة اللاسيكلونية مرونة النظام بشكل عام لأن فشل جزء واحد لا يوقف النظام بأكمله.
ومع ذلك، تمامًا مثل أنواع الواجهات الأخرى، تحتوي واجهات البرمجة المتماثلة اللاسيكلونية على عدة عيوب:
- هناك زيادة في التعقيد حول تسليم الرسائل، الترتيب، ومعالجة الأخطاء.
- تكون واجهات البرمجة المتماثلة اللاسيكلونية أكثر تحديًا للتصحيح والاختبار.
- تؤدي الأنظمة المبنية باستخدام واجهات البرمجة المتماثلة اللاسيكلونية غالبًا إلى التزامن النهائي، حيث لا يتم تعديل البيانات فورًا عبر جميع العناصر.
- يمكن أيضًا أن تزيد واجهات البرمجة المتماثلة اللاسيكلونية التكاليف بالنسبة للأنظمة الخاصة لمعالجة الرسائل.
حالات استخدام واجهات البرمجة المتماثلة اللاسيكلونية
هناك عدة ح
- تدفق البيانات في الوقت الفعلي – تُعتبر الواجهات البرمجية غير المتزامنة الخيار الأفضل لحاجات تدفق البيانات في الوقت الفعلي مثل أخبار وسائل التواصل الاجتماعي، تحديثات سوق المال، وبيانات أجهزة IoT. تولد هذه التطبيقات حجمًا كبيرًا من البيانات التي يجب معالجتها وتسليمها إلى العملاء في وقت قريب من الوقت الفعلي.
- التكامل مع أنظمة طرف ثالث – تعد الواجهات البرمجية غير المتزامنة مناسبة تمامًا للتكامل مع أنظمة طرف ثالث قد تكون لها أوقات استجابة غير متوقعة أو استئنافات خدمة متاحة.
- المهام الخلفية – أخيرًا، تستفيد التطبيقات التي تتطلب تنفيذ مهام خلفية – مثل إرسال رسائل البريد الإلكتروني، الإشعارات، أو معالجة الصور/الفيديو – من استخدام الواجهات البرمجية غير المتزامنة.
مقارنة جانبية بين REST، GraphQL، والواجهات البرمجية غير المتزامنة
لقد تعرفنا على جميع أنواع مخططات الواجهات البرمجية. حان الوقت لمقارنتها بجانب بعضها البعض حتى نتمكن من اتخاذ قرارات أفضل حول اختيار واحدة على الأخرى. يوضح الجدول أدناه هذه المقارنة عبر عدة معايير:
الجدول 1. مقارنة REST، GraphQL، والواجهات البرمجية غير المتزامنة
| Parameter | REST APIs | GraphQL APIs | Asynchronous APIs |
| Data fetching approach | Data is fetched with predefined endpoints | Clients specify the exact data requirements in the query | Data is passed in the form of asynchronous messages |
| Performance and scalability | Highly suitable for scalable applications; can suffer from overfetching and underfetching problems | Scalable; nested queries can be problematic | Highly scalable; efficient for real-time data processing |
| Flexibility and ease of use | Limited flexibility in querying data | High flexibility for querying data | Limited flexibility in querying data and requires understanding of an event-driven approach |
| Developer experience and learning curve | Well established and familiar to many developers | Moderate learning curve in terms of understanding the GraphQL syntax | Steeper learning curve |
| Real-time capabilities | Limited real-time capabilities, relying on techniques like polling and webhooks for updates | Real-time capabilities through subscriptions | Designed for real-time data processing; highly suitable for streaming applications |
| Tooling and ecosystem support | Abundant tooling and ecosystem support | Growing ecosystem | The need for specialized tools such as messaging platforms like RabbitMQ or Kafka |
الخاتمة
في هذا المقال، استكشفنا الاختلافات الرئيسية بين تصاميم API مختلفة: REST و GraphQL و APIs اللحظية. كما تعرضنا حالات تكون فيها نوع معين من الـ API أكثر ملاءمة من الآخرين. بعد ذلك، يتجه مشهد تطوير API نحو تحولات أخرى. التكنولوجيات الناشئة مثل التعلم الآلي وحوسبة الحافة والأجهزة الذكية ستدفع الطلبات الجديدة التي تتطلب تطور الأساليب API. أيضاً، مع نمو سريع للأنظمة الموزعة، ستلعب الـ APIs دوراً رئيسياً في تمكين الاتصال.
كمطور، من الضروري للغاية فهم قوى وعيوب كل أسلوب API واختيار الأسلوب الأكثر ملاءمة لمتطلبات معينة. هذا التفكير يمكن أن يساعد المطورين في استكشاف مشهد API بثقة.
هذا مقتطف من تقرير إحصائيات DZone لعام 2024، إدارة API الحديثة: توصيل المعماريات القائمة على البيانات مع الذكاء الاصطناعي والأتمتة والخدمات الدقيقة.
Source:
https://dzone.com/articles/understand-api-technologies-comparative-analysis