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

خمس بوابات مجانية ومفتوحة المصدر لإدارة واجهات برمجة التطبيقات (API) يمكنك تشغيلها من الطرفية: Kong OSS مع decK، و Tyk، و KrakenD، و Apache APISIX، و Gravitee، مع أوامر حقيقية.

INEZA Felin-Michel

INEZA Felin-Michel

10 يوليو 2026

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

Apidog للمؤسسات

النشر على الخوادم المحلية

SSO و RBAC

متوافق مع SOC 2

استكشف Apidog للمؤسسات

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

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

هذه قائمة بالبوابات مفتوحة المصدر حقًا ذات قصة حقيقية في سطر الأوامر: Kong Gateway OSS مع decK، Tyk، KrakenD Community Edition، Apache APISIX، و Gravitee. لكل منها ستحصل على الترخيص، وما تفعله واجهة سطر الأوامر (CLI) بالفعل، وأمر تثبيت وتشغيل حقيقي يمكنك لصقه. إذا كنت تريد المجال الأوسع، فإن ملخص أدوات إدارة واجهة برمجة التطبيقات مفتوحة المصدر يغطي المنصات؛ هذا المقال هو النسخة التي تركز على الطرفية أولاً. يستحق نص ترخيص Apache 2.0 الرسمي إلقاء نظرة سريعة عليه إذا لم تكن قد قرأت الشروط التي تعتمد عليها من قبل.

زر

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

ما الذي يجعل أداة واجهة سطر الأوامر (CLI) "مفتوحة المصدر" لإدارة واجهة برمجة التطبيقات (API)

ثلاثة أمور تفصل خيار المصدر المفتوح الحقيقي عن نسخة تجريبية مجانية ذات عد تنازلي.

الترخيص. ابحث عن Apache 2.0، MIT، أو MPL 2.0 على البوابة الأساسية، وليس فقط حزم تطوير برامج العميل (SDKs). يسمح لك Apache 2.0 بالاستضافة الذاتية والتعديل بحرية. MPL 2.0 (خيار Tyk) هو ترخيص من نوع copyleft على مستوى الملف؛ يمكنك دمجه مع كود احتكاري طالما بقيت ملفات MPL مفتوحة. أي شيء يحمل علامة "المصدر متاح" أو BSL ليس هو نفسه، لذا اقرأ ملف LICENSE الفعلي في المستودع.

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

مستودع مُصان وواجهة سطر أوامر عاملة. تحقق من نجوم GitHub، ولكن تحقق من سجل الالتزام (commit history) أكثر. البوابة التي يمكنك تكوينها بشكل تعريفي من سطر الأوامر، وتصنيفها في Git، وتشغيلها في CI هي جوهر هذه القائمة. للحصول على مفاهيم الإدارة العامة وراء كل هذا، راجع ما تغطيه إدارة واجهة برمجة التطبيقات (API) بالفعل.

بوابة Kong مفتوحة المصدر (مع decK)

بوابة Kong مفتوحة المصدر (Kong Gateway OSS) هي بناء Kong المرخص تحت Apache 2.0. تستمر شركة Kong Inc. في توفير إصدارات مفتوحة المصدر للأشخاص الذين يريدون كود Apache 2.0 فقط، بشكل منفصل عن إصدار Enterprise. يتم تكوين البوابة نفسها من خلال واجهة برمجة التطبيقات الإدارية الخاصة بها (Admin API)، ولكن الأداة التي تتعامل معها فعليًا هي decK.

decK هي واجهة سطر الأوامر للتكوين التصريحي من Kong. يمكنك تفريغ حالة البوابة قيد التشغيل إلى ملف YAML، وتعديله، ثم مزامنته مرة أخرى. يقوم بعمل مقارنة أولاً، لذلك ترى بالضبط ما سيتغير قبل حدوث التغيير، مما يجعل انحراف التكوين مرئيًا بدلاً من أن يكون صامتًا.

# Export the current Kong config to a file
deck gateway dump -o kong.yaml

# Push a declarative config back to the gateway
deck gateway sync kong.yaml

الأفضل لـ: البنية التحتية ككود لـ Kong. إذا كنت تدير Kong بالفعل وتريد مساراتك ومكوناتك الإضافية في Git مع المراجعة والتكامل المستمر (CI)، فإن decK هو الحل. قيود صادقة: إنه خاص بـ Kong، ويدير التكوين بدلاً من القيام بالتوثيق أو الاختبار. أنت أيضًا تقوم بتشغيل مكدس Kong الكامل، وهو أثقل من بوابة ثنائية واحدة.

Tyk

بوابة Tyk مفتوحة المصدر بموجب ترخيص Mozilla Public License 2.0. ترخيص MPL هو ترخيص copyleft على مستوى الملف: يجب أن تظل التغييرات على الملفات المرخصة تحت MPL مفتوحة، ولكن يمكنك تجميع البوابة مع مكونات إضافية احتكارية طالما أن هذه المكونات موجودة في ملفات منفصلة. تدعم البوابة الأساسية، المكتوبة بلغة Go، بروتوكولات REST، GraphQL، TCP، و gRPC.

الجزء المتعلق بسطر الأوامر الذي يستخدمه معظم الناس هو أداة التجميع (bundler)، والتي يتم شحنها داخل ملف البوابة الثنائي منذ الإصدار 2.8. تقوم بتجميع مكوناتك الإضافية المخصصة للبرامج الوسيطة في حزمة موقعة يمكن للبوابة تحميلها.

# Build a plugin bundle from your manifest and middleware files
tyk bundle build -o bundle.zip

الأفضل لـ: الفرق التي ترغب في توسيع البوابة بمكونات إضافية مخصصة للمصادقة أو التحويل وتحتاج إلى طريقة قابلة للتكرار لتعبئتها. قيود صادقة: تقتصر وظيفة واجهة سطر الأوامر (CLI) على التجميع، وليس التكوين التصريحي الكامل للبوابة بأكملها؛ لا تزال الكثير من إدارة Tyk تتم من خلال لوحة التحكم الخاصة بها (وهي الجزء المدفوع) أو واجهة برمجة تطبيقات البوابة مباشرة.

إصدار مجتمع KrakenD

KrakenD هي بوابة لا تعتمد على الحالة (stateless) وعالية الأداء، ويقدم إصدار المجتمع (Community Edition) مجموعة الميزات الأساسية الكاملة بموجب ترخيص Apache 2.0. الجزء المثير للاهتمام هو أنها لا تعتمد على الحالة: لا توجد قاعدة بيانات. يتم تعريف البوابة بالكامل بواسطة ملف تكوين، مما يجعلها مناسبة بشكل طبيعي لـ Git و CI.

ملف krakend الثنائي هو واجهة سطر الأوامر (CLI). يمكنك التحقق من صحة التكوينات باستخدام check وتشغيل البوابة باستخدام run. ولأنه ملف ثنائي واحد مكتوب بلغة Go، فإن التثبيت يتم بتنزيل واحد.

# Validate and lint your config before deploying
krakend check -c krakend.json --lint

# Run the gateway with that config
krakend run -c krakend.json

تتيح لك ميزة التكوين المرن (FC_ENABLE=1) تقسيم تكوين كبير إلى ملفات قوالب تحتوي على متغيرات، حتى تتمكن من الحفاظ على البيئات جافة (DRY). الأفضل لـ: البوابات التصريحية واللامتناهية التي يكون فيها ملف التكوين هو المصدر الوحيد للحقيقة. قيود صادقة: لا توجد ميزة استمرارية مدمجة أو واجهة مستخدم إدارية في إصدار المجتمع (CE)؛ تقوم بتركيب السلوك في التكوين بدلاً من النقر على المفاتيح، وهي ميزة إذا كنت تحب البنية التحتية ككود (IaC) وعقبة إذا لم تكن كذلك.

Apache APISIX

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

يحتوي APISIX على واجهة سطر أوامر للتحكم في عمليات دورة الحياة (lifecycle operations)، وواجهة برمجة تطبيقات إدارية REST (مرتبطة بـ 127.0.0.1 افتراضيًا) لإدارة المسارات والمكونات الإضافية. تبدأ واجهة سطر الأوامر (CLI) البوابة، توقفها، وتعيد تحميلها؛ apisix reload يلتقط تغييرات التكوين دون إسقاط الاتصالات.

# See the available control commands
apisix help

# Start the gateway, then hot-reload after a config change
apisix start
apisix reload

الأفضل لـ: التوجيه الديناميكي وعالي الإنتاجية حيث تريد تغيير المسارات والمكونات الإضافية في وقت التشغيل دون إعادة تشغيل، مدفوعة بواجهة برمجة تطبيقات الإدارة (Admin API). قيود صادقة: يعيش تكوين التوجيه في واجهة برمجة تطبيقات الإدارة بدلاً من دفعة CLI تصريحية واحدة، لذا فإن سير عمل "التكوين في Git" يعني عادةً برمجة استدعاءات Admin API أو إضافة أداة مثل ADC من APISIX فوقها.

Gravitee

منصة إدارة واجهة برمجة التطبيقات الأساسية من Gravitee مفتوحة المصدر بموجب ترخيص Apache 2.0. إنها أكثر من مجرد بوابة: يتضمن إصدار المجتمع (Community Edition) بوابة APIM (وقت التشغيل)، وواجهة برمجة تطبيقات APIM (واجهة إدارة REST)، ووحدة تحكم APIM. توجد ميزات Enterprise مثل واجهات برمجة التطبيقات غير المتزامنة الأصلية للأحداث في الإصدار المدفوع، ولكن جوهرها الذي يركز على REST هو مصدر مفتوح حقيقي يمكنك استضافته ذاتيًا.

تحتاج قصة سطر الأوامر إلى تحذير صادق. يتم تشغيل الإدارة اليومية لـ Gravitee من خلال واجهة برمجة تطبيقات الإدارة REST ووحدة التحكم الخاصة بها، وغالبًا ما يتم إجراء التثبيت الرسمي المستضاف ذاتيًا باستخدام Docker CLI. يوجد graviteeio-cli مدعوم من المجتمع على GitHub يغلف واجهة برمجة تطبيقات الإدارة لأتمتة الإجراءات عبر الوحدات النمطية، ولكنه أداة مجتمعية، وليست ثنائية من الطرف الأول، لذا تعامل مع حالة صيانتها بالطريقة التي ستتعامل بها مع أي مشروع مجتمعي قبل الاعتماد عليه.

# Run the Gravitee APIM gateway container (self-hosted, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

الأفضل لـ: الفرق التي تريد طبقة إدارة مفتوحة المصدر كاملة (بوابة بالإضافة إلى وحدة تحكم بالإضافة إلى واجهة برمجة تطبيقات إدارة للبرمجة النصية) بدلاً من مجرد وكيل. قيود صادقة: سطح الأتمتة الأصلي هو واجهة برمجة تطبيقات الإدارة REST، وليس واجهة سطر أوامر مصقولة واحدة؛ واجهة سطر الأوامر المجتمعية تسد الفجوة ولكنك تتحمل مخاطر صيانتها.

مكان Apidog (ولماذا ليس في قائمة المصادر المفتوحة)

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

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

# Install and authenticate the Apidog CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Run a test scenario in CI (exits non-zero on failure)
apidog run

تُخرج واجهة سطر الأوامر (CLI) JSON منظمًا مع agentHints.nextSteps، بحيث تتكامل بسلاسة في CI وفي مسارات عمل وكلاء الذكاء الاصطناعي؛ إذا كنت توجه عمل واجهة برمجة التطبيقات عبر Claude Code أو ما شابه ذلك، فإن إدارة واجهات برمجة التطبيقات دون مغادرة وكلاء الذكاء الاصطناعي الخاصين بك تغطي هذا النمط. كما يدعم استيراد وتصدير OpenAPI، وتشغيل السيناريوهات، وتشغيل عمليات المحاكاة من سطر الأوامر. يستعرض الدليل الكامل لـ Apidog CLI مجموعات الأوامر. فكر فيه كخيار الطبقة المجانية المتكاملة بجانب بوابة OSS المستضافة ذاتيًا، وليس بديلاً عنها.

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

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

اختر بناءً على سير العمل، وليس عدد النجوم. إذا كنت تدير Kong بالفعل، فإن decK هو أسرع مكسب. إذا كنت تريد بوابة لا تعتمد على الحالة يتم تعريفها بالكامل بواسطة ملف، فإن KrakenD يناسب. يتفوق APISIX في تغييرات التوجيه الديناميكية في وقت التشغيل؛ يمنحك Gravitee طبقة إدارة كاملة مع وحدة تحكم. للمقارنة الأوسع بما في ذلك المنصات التجارية، راجع أفضل أدوات إدارة واجهة برمجة التطبيقات لعام 2026 وزاوية إدارة واجهة برمجة التطبيقات بدون رأس إذا كنت تبني مكدسًا يعتمد على واجهة برمجة التطبيقات أولاً.

خلاصة

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

بالنسبة للتصميم والاختبار والمحاكاة والوثائق التي لا تتعامل معها البوابات، توفر الأداة المتكاملة تغطية لهذه الفجوة. قم بتنزيل Apidog وقم بتشغيل apidog run في مسار عملك لرؤية مسار واجهة سطر الأوامر (CLI)، ثم قم بربطه بالتكامل المستمر (CI) بجانب أي بوابة OSS تستقر عليها.

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات