أدوات CLI مجانية مفتوحة المصدر لإدارة الـ API

كانت إدارة واجهة برمجة التطبيقات (API) تعني سابقًا لوحة تحكم رسومية وفاتورة من مزود الخدمة. اليوم، يمكن تنفيذ معظم العمل من الطرفية: عرّف المسارات والمكونات الإضافية وحدود المعدل في ملف إعداد، احفظه في Git، ثم استخدم واجهة سطر الأوامر (CLI) لنشره إلى البوابة. بهذه الطريقة، يصبح ما تراجعه في طلب الدمج هو نفسه ما تنشره فعليًا.

جرّب Apidog اليوم

تكون زاوية المصدر المفتوح مهمة عندما تستضيف البوابة بنفسك. فالترخيص يحدد ما إذا كان بإمكانك تشغيل الأداة وتفريعها وشحنها دون تكلفة لكل مستخدم. تستخدم معظم الأدوات أدناه تراخيص Apache 2.0 أو MPL 2.0، ما يعني أن المصدر متاح ويمكنك تشغيله على بنيتك التحتية.

يغطي هذا الدليل بوابات API مفتوحة المصدر مع سير عمل عملي من الطرفية:

• Kong Gateway OSS مع decK
• Tyk
• KrakenD Community Edition
• Apache APISIX
• Gravitee

ستجد لكل أداة: الترخيص، ودور CLI الفعلي، وأوامر قابلة للنسخ. لمقارنة أوسع للمنصات، راجع أدوات إدارة واجهة برمجة التطبيقات مفتوحة المصدر. ومن المفيد أيضًا مراجعة نص ترخيص Apache 2.0 الرسمي.

ملاحظة: يظهر Apidog في نهاية المقال، لكنه ليس أداة مفتوحة المصدر. إنه منتج تجاري يوفر طبقة مجانية، ويُذكر هنا كأداة مكملة للبوابات وليس كبديل مفتوح المصدر عنها.

ما الذي يجعل CLI لإدارة API مفتوح المصدر فعلًا؟

استخدم هذه القائمة قبل اعتماد أي بوابة.

1. تحقق من الترخيص

ابحث عن ترخيص مثل Apache 2.0 أو MIT أو MPL 2.0 على مشروع البوابة الأساسي، وليس فقط على SDK أو مكتبة عميل.

• Apache 2.0: يسمح بالاستضافة الذاتية والتعديل والتوزيع.
• MPL 2.0: ترخيص copyleft على مستوى الملف؛ يجب أن تبقى تعديلات ملفات MPL مفتوحة، بينما يمكن أن تبقى المكونات المنفصلة احتكارية.
• Source Available أو BSL: لا يعادلان تلقائيًا المصدر المفتوح؛ اقرأ ملف LICENSE في المستودع.

2. تأكد من إمكانية الاستضافة الذاتية

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

3. اختبر سير عمل Git وCI

ابحث عن مشروع نشط وواجهة CLI قابلة للاستخدام. الهدف هو أن تتمكن من:

1. تعريف التكوين في ملفات.
2. حفظه في Git.
3. مراجعته عبر Pull Request.
4. التحقق منه في CI.
5. نشره من خط أنابيب آلي.

للسياق الأوسع، راجع ما تغطيه إدارة واجهة برمجة التطبيقات بالفعل.

Kong Gateway OSS مع decK

Kong Gateway OSS هو إصدار Kong المرخص تحت Apache 2.0. تُدار البوابة عبر Admin API، لكن أداة CLI الأساسية للتكوين التصريحي هي decK.

استخدم decK لتصدير الحالة الحالية إلى YAML، مراجعة التغييرات، ثم مزامنة التكوين مع البوابة.

# تصدير إعداد Kong الحالي إلى ملف
deck gateway dump -o kong.yaml

# مزامنة الإعداد التصريحي مع البوابة
deck gateway sync kong.yaml

سير عمل مقترح

1. صدّر الإعداد الحالي إلى kong.yaml.
2. أضف الملف إلى Git.
3. عدّل المسارات أو الخدمات أو المكونات الإضافية.
4. راجع الفرق في Pull Request.
5. شغّل deck gateway sync kong.yaml من CI أو من بيئة النشر.

الأفضل لـ: فرق تستخدم Kong وتريد إدارة المسارات والمكونات الإضافية كبنية تحتية ككود (IaC).

القيود: decK خاص بـ Kong ويركز على التكوين، لا على التوثيق أو الاختبار. كما أن تشغيل Kong الكامل أثقل من بوابة ثنائية واحدة.

Tyk

بوابة Tyk مفتوحة المصدر بموجب MPL 2.0. تدعم البوابة الأساسية المكتوبة بـ Go بروتوكولات REST وGraphQL وTCP وgRPC.

أمر CLI العملي الشائع هو أداة التجميع المضمنة في ملف البوابة الثنائي منذ الإصدار 2.8. استخدمها لتعبئة مكونات middleware المخصصة في حزمة يمكن للبوابة تحميلها.

# إنشاء حزمة مكونات إضافية من manifest وملفات middleware
tyk bundle build -o bundle.zip

متى تستخدمه؟

استخدم Tyk عندما تحتاج إلى مكونات إضافية مخصصة للمصادقة أو التحويل أو منطق middleware، وتريد عملية تعبئة قابلة للتكرار في CI.

الأفضل لـ: فرق تحتاج إلى تجميع مكونات إضافية مخصصة وتعمل عبر بروتوكولات متعددة.

القيود: CLI يركز على التجميع، وليس على إدارة تعريفية كاملة للبوابة. الكثير من إدارة Tyk يتم عبر لوحة التحكم المدفوعة أو Gateway API مباشرة.

KrakenD Community Edition

KrakenD بوابة عالية الأداء وعديمة الحالة (stateless). يوفر إصدار المجتمع الميزات الأساسية تحت Apache 2.0.

الميزة الرئيسية هنا هي عدم وجود قاعدة بيانات: ملف التكوين هو المصدر الوحيد للحقيقة. هذا يجعل KrakenD مناسبًا لـ Git وCI مباشرة.

# التحقق من صحة الإعداد وتنفيذ lint قبل النشر
krakend check -c krakend.json --lint

# تشغيل البوابة باستخدام الإعداد نفسه
krakend run -c krakend.json

سير عمل مقترح

# 1. تحقق من الإعداد في CI
krakend check -c krakend.json --lint

# 2. انشر فقط إذا نجح التحقق
krakend run -c krakend.json

يمكنك استخدام التكوين المرن عبر FC_ENABLE=1 لتقسيم الإعدادات الكبيرة إلى قوالب وملفات متغيرات، ما يساعد على إبقاء إعدادات البيئات المختلفة قابلة لإعادة الاستخدام.

الأفضل لـ: بوابة تعريفية بالكامل، حيث يكون ملف التكوين هو المصدر الوحيد للحقيقة.

القيود: لا يوفر إصدار المجتمع واجهة إدارة أو استمرارية مدمجة. يجب تعريف السلوك في التكوين بدلًا من تغييره من لوحة تحكم.

Apache APISIX

Apache APISIX مشروع رفيع المستوى تابع لمؤسسة Apache Software Foundation ومرخص تحت Apache 2.0. هذا مهم لأن إصدار OSS هو المشروع الأساسي نفسه، وليس نسخة مجتمع محدودة من منتج بائع.

يوفر APISIX:

• CLI لعمليات دورة الحياة.
• Admin API من نوع REST لإدارة المسارات والمكونات الإضافية.
• إعادة تحميل للتكوين دون قطع الاتصالات.

# عرض أوامر التحكم المتاحة
apisix help

# تشغيل البوابة
apisix start

# إعادة تحميل التكوين بعد التعديل
apisix reload

تكون Admin API مرتبطة بـ 127.0.0.1 افتراضيًا. استخدم apisix reload لالتقاط تغييرات التكوين دون إعادة تشغيل كاملة.

الأفضل لـ: توجيه ديناميكي عالي الإنتاجية وتحديثات وقت التشغيل للمسارات والمكونات الإضافية.

القيود: عادةً ما تعيش إعدادات التوجيه في Admin API بدلًا من دفعة CLI تعريفية واحدة. إذا أردت سير عمل “التكوين في Git”، ستحتاج إلى أتمتة استدعاءات Admin API أو استخدام أداة إضافية مثل ADC من APISIX.

Gravitee

منصة Gravitee الأساسية لإدارة API مفتوحة المصدر تحت Apache 2.0. وهي أكثر من مجرد بوابة، إذ يشمل إصدار المجتمع:

• بوابة APIM لوقت التشغيل.
• APIM REST API للإدارة.
• وحدة تحكم APIM.

تتوفر بعض ميزات Enterprise، مثل واجهات برمجة التطبيقات غير المتزامنة الأصلية للأحداث، في الإصدار المدفوع. لكن جوهر REST قابل للاستضافة الذاتية ومفتوح المصدر.

لتشغيل البوابة ذاتيًا باستخدام Docker:

# تشغيل حاوية Gravitee APIM Gateway ذاتيًا
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

تعتمد الإدارة اليومية عادةً على REST Management API ووحدة التحكم. يوجد أيضًا graviteeio-cli من المجتمع على GitHub لتغليف واجهة الإدارة وأتمتة الإجراءات، لكنه ليس أداة رسمية من الطرف الأول؛ تحقق من نشاط صيانته قبل اعتماده في الإنتاج.

الأفضل لـ: فرق تريد طبقة إدارة OSS كاملة تضم بوابة ووحدة تحكم وواجهة إدارة قابلة للبرمجة.

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

مكان Apidog ولماذا لا يندرج ضمن أدوات المصدر المفتوح

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

تتعامل البوابات مع حركة المرور والمسارات والمكونات الإضافية، لكنها لا تغطي بالضرورة:

• تصميم مخطط API.
• اختبار نقاط النهاية.
• إنشاء التوثيق.
• محاكاة الاستجابات قبل توفر الواجهة الخلفية.

غالبًا ما يتطلب تجميع هذه المهام أدوات منفصلة مثل Spectral وopenapi-generator وخادم mock وNewman. يجمع Apidog التصميم والاختبار والمحاكاة والتوثيق في مساحة عمل واحدة، ويوفر apidog-cli لتنفيذ هذه المهام من الطرفية.

# تثبيت Apidog CLI والمصادقة
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# تشغيل سيناريو اختبار في CI
# ينتهي الأمر برمز غير صفري عند الفشل
apidog run

تنتج CLI مخرجات JSON منظمة تتضمن agentHints.nextSteps، ما يجعلها مناسبة لخطوط CI ومسارات عمل وكلاء الذكاء الاصطناعي. لمزيد من التفاصيل، راجع إدارة واجهات برمجة التطبيقات دون مغادرة وكلاء الذكاء الاصطناعي.

كما تدعم الأداة استيراد وتصدير OpenAPI، وتشغيل السيناريوهات، وتشغيل المحاكاة من CLI. راجع الدليل الكامل لـ Apidog CLI لمعرفة مجموعات الأوامر.

فكّر في Apidog كطبقة متكاملة للتصميم والاختبار بجانب بوابة OSS مستضافة ذاتيًا، وليس كبديل عنها.

كيفية الاختيار

الأداة	الأفضل لـ	الترخيص	مفتوح المصدر؟	CLI / الأمر
Kong Gateway OSS + decK	تكوين Kong كبنية تحتية ككود في Git	Apache 2.0	نعم	deck gateway sync
Tyk	تجميع المكونات الإضافية المخصصة ودعم بروتوكولات متعددة	MPL 2.0	نعم	tyk bundle build
KrakenD Community Edition	بوابة عديمة الحالة وتكوين ككود	Apache 2.0	نعم	krakend run
Apache APISIX	توجيه ديناميكي عالي الإنتاجية	Apache 2.0	نعم، مشروع ASF	apisix start / apisix reload
Gravitee	طبقة إدارة OSS كاملة مع وحدة تحكم	Apache 2.0	نعم، في الإصدار الأساسي	Docker CLI / REST API
Apidog CLI	تصميم واختبار ومحاكاة وتوثيق في مكان واحد	فريميوم	لا	apidog run

اختر بناءً على سير العمل الفعلي، لا على عدد نجوم GitHub فقط:

• تستخدم Kong بالفعل؟ ابدأ بـ decK.
• تريد بوابة بلا قاعدة بيانات وملف إعداد واحد؟ اختر KrakenD.
• تحتاج تغييرات توجيه ديناميكية في وقت التشغيل؟ اختر APISIX.
• تريد بوابة ووحدة تحكم وواجهة إدارة كاملة؟ استخدم Gravitee.
• تحتاج طبقة موحدة لتصميم API واختبارها ومحاكاتها؟ أضف Apidog بجانب بوابتك.

للمقارنة الأوسع، راجع أفضل أدوات إدارة واجهة برمجة التطبيقات لعام 2026 وإدارة واجهة برمجة التطبيقات بدون رأس.

خلاصة

إدارة API مفتوحة المصدر من الطرفية ناضجة وقابلة للتطبيق في الإنتاج. Kong Gateway OSS مع decK وTyk وKrakenD CE وApache APISIX وGravitee كلها قابلة للاستضافة الذاتية، وتستخدم تراخيص Apache 2.0 أو MPL 2.0، وتوفر مسارًا للتشغيل والأتمتة من الطرفية.

ابدأ بتحديد نموذج النشر الذي تحتاجه:

1. تكوين تعريفـي في Git.
2. تحديثات ديناميكية وقت التشغيل.
3. مكونات إضافية مخصصة.
4. طبقة إدارة كاملة.
5. أدوات تصميم واختبار مكملة للبوابة.

للتصميم والاختبار والمحاكاة والتوثيق، يمكنك تنزيل Apidog وتشغيل apidog run ضمن خط CI بجانب بوابة OSS التي تختارها.