أفضل الممارسات لبناء واجهات برمجة التطبيقات (APIs) الموثوقة

مع زيادة حجم وعدد واجهات برمجة التطبيقات (APIs) الخاصة بك، تزداد الحاجة لجعلها أكثر موثوقية وقوة.

تتناول هذه المقالة أفضل الممارسات لبناء واجهات برمجة تطبيقات موثوقة من خلال تقديم نوع خاص من الخوادم العكسية يُعرف باسم بوابات واجهات برمجة التطبيقات (API Gateways).

سنناقش:

1. مشكلات تصميمات واجهات برمجة التطبيقات التقليدية
2. ما هي بوابات واجهات برمجة التطبيقات
3. كيف تحسّن بوابات واجهات برمجة التطبيقات من واجهات برمجة التطبيقات
4. أنماط وأمثلة باستخدام بوابات واجهات برمجة التطبيقات

ولكن أولاً، ما هي واجهات برمجة التطبيقات "الموثوقة"؟

ما الذي يجعل واجهة برمجة التطبيقات موثوقة؟

كمزود خدمة، قد يكون لديك اتفاقيات مستوى الخدمة (SLAs) مع عملائك، والتي عادةً ما تُقاس بوقت التشغيل (uptime) — وهو مقدار الوقت الذي تكون فيه الخدمة مضمونة للعمل بشكل متصل وفعال.

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

لنلقِ نظرة على هذه العوامل والأسئلة التي تطرحها:

1. الكمون (Latency): ما مدى سرعة استجابة واجهة برمجة التطبيقات للطلبات؟
2. الأمان (Security): من يمكنه الوصول إلى واجهة برمجة التطبيقات؟ هل هي آمنة؟
3. تكرار التوقف (Downtime Frequency): كم مرة تتوقف واجهة برمجة التطبيقات عن العمل؟
4. الاتساق (Consistency): هل نقاط نهاية واجهة برمجة التطبيقات ثابتة؟ هل يحتاج المستهلكون إلى تغيير أكوادهم بشكل متكرر؟
5. المراقبة والإبلاغ (Monitoring and Reporting): هل يمكنك مراقبة المشكلات والأعطال في واجهة برمجة التطبيقات؟ هل تقوم بالإبلاغ عنها للمستهلكين؟

مع تحول المؤسسات إلى البنى التحتية السحابية (cloud-native)، يصبح من الصعب على فرق التطوير مراعاة هذه العوامل في كل خدمة من خدماتهم. ومع توسع هذه الأنظمة، سيكون من الأسهل تفويض هذه المسؤوليات إلى نظام واحد منفصل. فلنرحب ببوابات واجهات برمجة التطبيقات!

بوابة واجهات برمجة التطبيقات، نقطة الدخول الموحدة

تعمل بوابة واجهات برمجة التطبيقات كوسيط بين عملائك وواجهات برمجة التطبيقات الخاصة بك. ستقبل جميع حركة المرور (مكالمات واجهات برمجة التطبيقات) مثل الخوادم العكسية، وتوجه الطلب إلى الخدمات المطلوبة في الخلفية، وتعيد النتائج المطلوبة.

يمكن أن تكون بوابة واجهات برمجة التطبيقات النقطة المركزية التي تتعامل مع جميع مخاوف المصادقة، والأمان، والتحكم في حركة المرور، والمراقبة، مما يسمح لمطوري واجهات برمجة التطبيقات بالتركيز على احتياجات الأعمال ويجعل من السهل تحسين الموثوقية.

هناك العديد من عروض بوابات واجهات برمجة التطبيقات مفتوحة المصدر والمدارة المتاحة. في هذه المقالة، سأستخدم Apache APISIX.

سيصف القسم التالي بعض أفضل الممارسات لجعل واجهات برمجة التطبيقات الخاصة بك موثوقة باستخدام بوابات واجهات برمجة التطبيقات.

أفضل ممارسات الموثوقية باستخدام بوابات واجهات برمجة التطبيقات

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

سأقسم هذه الأنماط إلى ثلاث فئات:

1. المصادقة والأمان
2. المراقبة والملاحظة
3. التحكم في الإصدارات وعدم التوقف

سنناقش كل فئة بالتفصيل أدناه.

المصادقة والأمان

مصادقة المستخدم

تؤمن الطلبات المصادق عليها باستخدام بوابات واجهات برمجة التطبيقات التفاعلات بين العميل وواجهة برمجة التطبيقات. بعد أن يتم مصادقة العميل، يمكن لبوابة واجهات برمجة التطبيقات استخدام تفاصيل العميل التي تم الحصول عليها للتحكم الدقيق.

يتعامل APISIX مع المصادقة مباشرة من خلال الإضافات مثل key-auth و jwt-auth. كما يدعم APISIX المصادقة باستخدام OAuth وأنظمة التحكم في الوصول القائمة على الأدوار مثل wolf من خلال إضافات مثل openid-connect و wolf-rbac على التوالي.

تحديد معدل الطلبات

يمكن أن تؤدي الزيادات المتعمدة (هجمات حجب الخدمة DoS) أو غير المتعمدة (العملاء الذين يقدمون عددًا كبيرًا من الطلبات) في حركة المرور إلى إسقاط واجهات برمجة التطبيقات مثل بيت من ورق. سيؤدي إعداد تحديد معدل الطلبات إلى تحسين موثوقية أنظمتك في التعامل مع مثل هذه السيناريوهات.

يمكنك إعداد تحديد معدل الطلبات على بوابة واجهات برمجة التطبيقات، وإذا زاد عدد الطلبات عن حد معين، يمكن لبوابة واجهات برمجة التطبيقات إما تأخير أو رفض الطلبات الزائدة.

مع APISIX، يمكنك استخدام أي من الإضافات الثلاث لتكوين حدود المعدل بناءً على عدد الطلبات، وعدد الطلبات المتزامنة لكل عميل، والعدد (limit-req، limit-conn، limit-count).

المراقبة والملاحظة

تسير موثوقية واجهة برمجة التطبيقات وإعدادات المراقبة جنبًا إلى جنب. ويمكنك مراقبة مقاييس الموثوقية الخاصة بك من خلال إعداد المراقبة على بوابة واجهات برمجة التطبيقات.

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

مع بعض التكوين، ستتمكن أيضًا من التنبؤ وتوقع حركة المرور المستقبلية، مما يساعدك على التوسع بشكل موثوق.

يحتوي APISIX على إضافات تتكامل مع منصات/مواصفات التسجيل (Apache SkyWalking، RocketMQ)، والمقاييس (Prometheus، Datadog)، والتتبع (OpenTelemetry، Zipkin). يمكنك قراءة المزيد عن ملاحظة واجهات برمجة التطبيقات باستخدام إضافات APISIX.

التحكم في الإصدارات وعدم التوقف

الإصدار التجريبي (Canary Release)

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

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

في البداية، ستوجه بوابة واجهات برمجة التطبيقات جميع حركة المرور إلى الإصدار القديم من واجهة برمجة التطبيقات.

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

أخيرًا، يمكنك توجيه جميع حركة المرور إلى واجهة برمجة التطبيقات الجديدة.

يستخدم APISIX إضافة traffic-split التي تتيح لك التحكم في حركة المرور إلى خدماتك. يمكنك استخدامها لإعداد الإصدارات التجريبية أو تكوين الإصدار المخصص الخاص بك.

كسر الدائرة (Circuit Breaking)

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

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

يأتي APISIX مع إضافة api-breaker التي تنفذ هذا النمط.

إعادة التوجيه (Redirects)

عندما تقوم بتحديث واجهات برمجة التطبيقات الخاصة بك، قد تخضع نقاط نهايتها لتغييرات. تقليديًا، كان هذا يعني أن تطبيق العميل يجب أن يرسل الطلبات إلى /new-api-endpoint بدلاً من /old-api-endpoint، مما يعني أن مستهلكيك يجب أن يغيروا كل استدعاء يدويًا إلى نقطة نهاية واجهة برمجة التطبيقات هذه.

إذا لم يتم توقع ذلك، يمكن أن يؤدي إلى كسر تطبيقات العملاء.

مع بوابة واجهات برمجة التطبيقات، يمكنك توفير طبقة تجريد وإعادة توجيه الطلبات إلى /new-api-endpoint دون الحاجة إلى تغيير العملاء لطلباتهم. مع رموز حالة إعادة التوجيه والرسائل المناسبة، يمكنك إيقاف استخدام /old-api-endpoint تدريجيًا دون أن يعاني مستهلكوك من أي توقف.

مع APISIX، يمكنك استخدام إضافة redirect لتكوين إعادة التوجيه.

الخلاصة

عندما تصبح الموثوقية مصدر قلق رئيسي، يصبح من الواضح أن بوابات واجهات برمجة التطبيقات ضرورية مع تحول المزيد من المؤسسات إلى تقسيم أنظمتها الكبيرة إلى خدمات صغيرة (microservices) والانتقال إلى البنى التحتية السحابية.

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

حالات الاستخدام المذكورة هنا تلامس فقط سطح إمكانيات بوابة واجهات برمجة التطبيقات. يمكنك معرفة المزيد عن بوابات واجهات برمجة التطبيقات و Apache APISIX على apisix.apache.org.