ربط طلبات API باستخدام API Gateway

مع زيادة عدد واجهات برمجة التطبيقات (APIs) التي تحتاج إلى التكامل، تصبح إدارة تعقيد تفاعلات واجهات برمجة التطبيقات أكثر صعوبة. باستخدام بوابة API، يمكننا إنشاء سلسلة من طلبات واجهات برمجة التطبيقات، مما يقسم سير عمل واجهات برمجة التطبيقات إلى خطوات أصغر وأكثر قابلية للإدارة. على سبيل المثال، في موقع تسوق عبر الإنترنت عندما يبحث العميل عن منتج، يمكن للمنصة إرسال طلب إلى واجهة برمجة التطبيقات الخاصة بالبحث عن المنتج، ثم إرسال طلب إلى واجهة برمجة التطبيقات الخاصة بتفاصيل المنتج لاسترداد المزيد من المعلومات حول المنتجات. في هذه المقالة، سنقوم بإنشاء مكون إضافي مخصص لبوابة Apache APISIX API Gateway للتعامل مع طلبات العملاء التي يجب استدعاؤها بالتسلسل.

أهداف التعلم

ستتعلم ما يلي خلال المقالة:

• ما هي طلبات واجهات برمجة التطبيقات المتسلسلة؟
• مثال على استدعاءات واجهات برمجة التطبيقات المتسلسلة.
• كيفية بناء مكون إضافي مخصص لـ Apache APISIX لمعالجة الطلبات المتسلسلة.
• عرض توضيحي لمكون إضافي لمعالجة الطلبات المتسلسلة.

ما هي طلبات واجهات برمجة التطبيقات المتسلسلة ولماذا نحتاجها؟

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

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

مكون إضافي مخصص لمعالجة الطلبات المتسلسلة لـ Apache APISIX

يمكن أن تكون بوابة API المكان المناسب لتنفيذ هذه الوظيفة لأنها يمكن أن تعترض جميع طلبات تطبيق العميل وتوجيهها إلى الوجهات المقصودة. سنستخدم Apache APISIX لأنه حل شائع مفتوح المصدر لبوابة API مع مجموعة من المكونات الإضافية المدمجة. ومع ذلك، في وقت تطوير هذه المقالة، لم يكن لدى APISIX دعم رسمي لمكون إضافي لمعالجة الطلبات المتسلسلة. بمعرفة قدرات تطوير المكونات الإضافية المخصصة لـ APISIX، قررنا تقديم مكون إضافي جديد يمكن أن يوفر نفس الميزة. هناك مستودع على GitHub يحتوي على الكود المصدري مكتوب بلغة Lua ووصف لمكون إضافي لمعالجة الطلبات المتسلسلة.

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

لنفهم استخدام هذا المكون الإضافي بمثال. لنفترض أن لديك واجهتي برمجة تطبيقات - واحدة تقوم بطلبات GET /credit_cards لاسترداد معلومات بطاقات الائتمان وأخرى تستقبل بيانات الاستجابة السابقة في جسم طلب POST /filter ثم تقوم بتصفية البيانات الحساسة (مثل رقم بطاقة الائتمان وتاريخ انتهاء الصلاحية) قبل إعادة الاستجابة إلى العميل. لأن نقطة نهاية واجهة برمجة التطبيقات الخاصة ببطاقات الائتمان تُرجع معلومات حساسة لا يجب الكشف عنها لأطراف غير مصرح لها. يوضح الرسم البياني التالي تدفق البيانات العام:

1. عندما يقوم العميل بطلب إلى نقطة نهاية واجهة برمجة التطبيقات الخاصة ببطاقات الائتمان في بوابة API لاسترداد جميع معلومات بطاقات الائتمان، تقوم بوابة API بتوجيه طلب لاسترداد بيانات بطاقات الائتمان من خدمة الخلفية الخاصة ببطاقات الائتمان.
2. إذا كان الطلب ناجحًا وأرجع بيانات بطاقات الائتمان، فإنه يمررها إلى الخطوة التالية في الأنبوب وهي خدمة الأمان.
3. عند استلام الاستجابة المصفاة من خدمة الأمان، يتم إرجاع الاستجابة المجمعة إلى العميل.

عرض توضيحي لمكون إضافي لمعالجة الطلبات المتسلسلة

لهذا العرض التوضيحي، سنستفيد من مشروع تجريبي آخر على GitHub حيث يمكنك العثور على جميع أمثلة أوامر curl المستخدمة في هذا البرنامج التعليمي، وتشغيل APISIX وتمكين مكون إضافي مخصص دون تكوين إضافي باستخدام ملف Docker compose.yml.

المتطلبات الأساسية

• Docker يستخدم لتثبيت etcd وAPISIX في حاويات.
• curl يستخدم لإرسال الطلبات إلى واجهة برمجة تطبيقات إدارة APISIX. يمكنك أيضًا استخدام أدوات سهلة مثل Postman للتفاعل مع واجهة برمجة التطبيقات.

الخطوة 1: تثبيت وتشغيل APISIX وetcd

يمكنك بسهولة تثبيت APISIX وetcd عن طريق تشغيل docker compose up من مجلد المشروع الرئيسي بعد نسخ/استنساخ المشروع. قد تلاحظ وجود حجم ./custom-plugins:/opt/apisix/plugins:ro محدد في ملف docker-compose.yml. هذا يربط المجلد المحلي ./custom-plugins حيث يوجد ملف pipeline-request.lua مع تنفيذ المكون الإضافي المخصص كحجم قراءة فقط في حاوية docker في المسار /opt/apisix/plugins. يسمح هذا بإضافة مكونات إضافية مخصصة إلى APISIX أثناء التشغيل (هذا الإعداد ينطبق فقط إذا كنت تقوم بتشغيل APISIX باستخدام docker).

الخطوة 2: إنشاء أول Route مع مكون إضافي لمعالجة الطلبات المتسلسلة

بمجرد تشغيل APISIX، نستخدم أمر cURL لإرسال طلب HTTP PUT إلى نقطة نهاية /routes في واجهة برمجة تطبيقات إدارة APISIX لإنشاء أول Route يستمع لمسار URI /my-credit-cards.

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/1' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '{
   "uri":"/my-credit-cards",
   "plugins":{
      "pipeline-request":{
         "nodes":[
            {
               "url":"https://random-data-api.com/api/v2/credit_cards"
            },
            {
               "url":"http://127.0.0.1:9080/filter"
            }
         ]
      }
   }
}'

الجزء المهم من التكوين هو قسم "plugins"، الذي يحدد أنه يجب استخدام المكون الإضافي "pipeline-request" لهذا Route. يحتوي تكوين المكون الإضافي على مصفوفة "nodes"، التي تحدد تسلسل طلبات واجهات برمجة التطبيقات التي يجب تنفيذها في الأنبوب. يمكنك تعريف واجهة برمجة تطبيقات واحدة أو عدة واجهات هناك. في هذه الحالة، يتكون الأنبوب من عقدتين: العقدة الأولى ترسل طلبًا إلى واجهة برمجة التطبيقات https://random-data-api.com/api/v2/credit_cards لاسترداد بيانات بطاقات الائتمان، والعقدة الثانية ترسل طلبًا إلى واجهة برمجة تطبيقات محلية في http://127.0.0.1:9080/filter لتصفية البيانات الحساسة من معلومات بطاقات الائتمان. ستكون واجهة برمجة التطبيقات الثانية مجرد وظيفة بدون خادم باستخدام المكون الإضافي serverless-pre-function لـ APISIX. تعمل فقط كخدمة خلفية لتعديل الاستجابة من واجهة برمجة التطبيقات الأولى.

الخطوة 3: إنشاء Route الثاني مع المكون الإضافي serverless

بعد ذلك، نقوم بتكوين Route جديد بالمعرف 2 يتعامل مع الطلبات إلى نقطة النهاية /filter في الأنبوب. كما يتم تمكين المكون الإضافي serverless-pre-function الموجود في APISIX حيث نحدد وظيفة Lua التي يجب تنفيذها بواسطة المكون الإضافي. تقوم هذه الوظيفة ببساطة باسترداد جسم الطلب من الاستجابة السابقة، واستبدال حقل رقم بطاقة الائتمان، وترك بقية الاستجابة دون تغيير. أخيرًا، تقوم بتعيين جسم الاستجابة الحالي إلى جسم الطلب المعدل وإرسال استجابة HTTP 200 مرة أخرى إلى العميل. يمكنك تعديل هذا البرنامج النصي ليناسب احتياجاتك، مثل استخدام الجسم المفكوك لإجراء مزيد من المعالجة أو التحقق.

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/2' \
--header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
--header 'Content-Type: application/json' \
--data-raw '
{
  "uri": "/filter",
  "plugins":{
    "serverless-pre-function": {
            "phase": "access",
            "functions": [
                "return function(conf, ctx)
                    local core = require(\"apisix.core\")
                    local cjson = require(\"cjson.safe\")

                    -- Get the request body
                    local body = core.request.get_body()
                    -- Decode the JSON body
                    local decoded_body = cjson.decode(body)

                    -- Hide the credit card number
                    decoded_body.credit_card_number = \"****-****-****-****\"
                    core.response.exit(200, decoded_body);
                end"
            ]
        }
    }
}'

الخطوة 3: اختبار الإعداد

حان الوقت الآن لاختبار التكوين العام. باستخدام أمر curl التالي، نرسل طلب HTTP GET إلى نقطة النهاية http://127.0.0.1:9080/my-credit-cards.

curl http://127.0.0.1:9080/my-credit-cards

لدينا Route المقابل المكون في الخطوة الثانية لاستخدام المكون الإضافي pipeline-request مع عقدتين، سيؤدي هذا الطلب إلى تشغيل الأنبوب لاسترداد معلومات بطاقات الائتمان من نقطة النهاية https://random-data-api.com/api/v2/credit_cards، وتصفية البيانات الحساسة باستخدام نقطة النهاية http://127.0.0.1:9080/filter، وإعادة الاستجابة المعدلة إلى العميل. انظر الناتج:

{
   "uid":"a66239cd-960b-4e14-8d3c-a8940cedd907",
   "credit_card_expiry_date":"2025-05-10",
   "credit_card_type":"visa",
   "credit_card_number":"****-****-****-****",
   "id":2248
}

كما ترى، يتم استبدال رقم بطاقة الائتمان في جسم الطلب (في الواقع، هو الاستجابة من استدعاء واجهة برمجة التطبيقات الأولى في السلسلة) بعلامات النجمة.

ملخص

حتى الآن، تعلمنا أن مكوننا الإضافي المخصص لمعالجة الطلبات المتسلسلة لبوابة Apache APISIX API Gateway يسمح لنا بتعريف سلسلة من استدعاءات واجهات برمجة التطبيقات كأنبوب بترتيب محدد. يمكننا أيضًا استخدام هذا المكون الإضافي الجديد مع مجموعة من المكونات الإضافية الحالية لتمكين المصادقة والأمان وميزات أخرى لبوابة API لنقاط نهاية واجهات برمجة التطبيقات الخاصة بنا.

موارد ذات صلة

• معالجة الطلبات المجمعة باستخدام بوابة API