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

لا تزال معظم مهام عمل المطورين تتم من خلال الطرفية (terminal)، وتميل الأدوات التي تصمد عبر السنوات إلى أن تشترك في صفة واحدة: أنها مفتوحة المصدر. يمكنك قراءة الكود، واستضافة أي شيء يشغل خادمًا بنفسك، ولن تصادف أبدًا ترخيصًا للمقعد أو جدار "اتصل بالمبيعات". عندما تكون الأداة مرخصة تحت رخصة MIT أو Apache وموجودة على GitHub، فإنك تحصل أيضًا على إشارة صيانة يمكنك التحقق منها بنفسك، بالإضافة إلى حرية تفريعها (fork) إذا توقف المشروع.

هذا المقال هو قائمة منسقة لأدوات واجهة سطر الأوامر (CLI) المجانية والمفتوحة المصدر حقًا والتي تستحق مكانًا في مهام تطوير واجهات برمجة التطبيقات (API) والعمل الخلفي اليومي. كل أداة هنا تأتي بترخيص متساهل أو ترخيص Copyleft، وتحتفظ بمصدرها على GitHub، ولا تكلف شيئًا للتشغيل. العدسة هنا هي الترخيص والارتباط، وليس الحجم الخام أو سرعة التشغيل.

ستحصل على سبع أدوات للحلقة الأساسية: إجراء الطلبات، تحليل JSON، اختبار تدفقات HTTP، العمل مع GitHub، وكشف الخادم المحلي للإنترنت. كل إدخال يذكر الترخيص، يربط بالمستودع (repo)، ويعرض أمرًا حقيقيًا واحدًا حتى تتمكن من رؤيته يعمل. هناك أيضًا ملاحظة صادقة حول مكان أداة تجارية ذات طبقة مجانية، معلمة بوضوح حتى لا تخطئها أبدًا على أنها إدخال مفتوح المصدر.

ما الذي يجعل أداة واجهة سطر الأوامر "مفتوحة المصدر" للتطوير؟

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

• الترخيص. تأتي بترخيص معتمد من OSI: MIT، Apache 2.0، BSD، أو GPL. وهذا ما يسمح لك باستخدامها تجاريًا، واستضافتها ذاتيًا، وتفريعها دون طلب الإذن.
• المصدر على GitHub (أو ما يعادله). يمكنك قراءة كل سطر، وتقديم المشاكل، والحكم على الصيانة من تاريخ الالتزامات (commit history) وتواتر الإصدارات.
• لا يوجد ارتباط (No lock-in). لا يوجد حساب إجباري، ولا قياس عن بعد (telemetry) لا يمكنك إيقافه، ولا مكون خادم تجبر على استئجاره. إذا كانت تشغل خدمة، يمكنك تشغيل تلك الخدمة بنفسك.

النجوم والالتزامات الأخيرة مهمة أيضًا، ولكنها ثانوية. أداة MIT هادئة ومستقرة أفضل من أداة عصرية بترخيص متاح المصدر يقيد الاستخدام التجاري. تحقق من ملف LICENSE قبل أن توحد أي شيء.

curl: عميل HTTP العالمي

curl هي الأداة التي تقاس بها جميع أدوات HTTP الأخرى تقريبًا. تتحدث عشرات البروتوكولات، وتشحن مع كل نظام تشغيل تقريبًا بشكل افتراضي، وتمت صيانتها بشكل مستمر منذ عام 1996. وهي مرخصة تحت ترخيص curl المتساهل (مشتق من MIT/X)، ومصدرها موجود على github.com/curl/curl.

لعمل واجهات برمجة التطبيقات، curl هي أداة الطلبات الأقل تعقيدًا. إنها مثبتة بالفعل، لذا يمكن لأي سكريبت أو مهمة CI الاعتماد عليها.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue","body":"Filed from curl"}'

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

HTTPie: curl مع إخراج سهل الاستخدام

HTTPie هو عميل HTTP حديث مصمم للبشر، وليس فقط للسيرفرات. تقرأ الطلبات مثل اللغة الإنجليزية العادية، وJSON هو نوع الجسم الافتراضي، وتعود الاستجابات ملونة ومنسقة. وهو مرخص تحت BSD-3-Clause ومفتوح على github.com/httpie/cli.

ثبّته باستخدام pip، ثم استخدم الأمر http:

pip install httpie
http POST httpbin.org/post name=apidog role=platform

هذا هو الطلب بأكمله. يصبح name=apidog حقل JSON تلقائيًا، وتطبع الرؤوس والحالة بألوان، ويتم تنسيق الجسم بشكل جميل دون الحاجة إلى أداة ثانية. الأفضل في: الاستكشاف التفاعلي وتصحيح الأخطاء يدويًا. الحد الصادق هو أنه حزمة Python، لذا فإن تثبيته أثقل من ثنائي ثابت واحد، وفي صور CI الضيقة قد تظل بحاجة إلى curl.

jq: معالج JSON الذي تحتاجه كل تدفقات البيانات

تعيد واجهات برمجة التطبيقات JSON، وjq هي الطريقة التي تقطع بها البيانات من سطر الأوامر. تقوم بالتصفية، وإعادة التشكيل، واستخراج الحقول باستخدام لغة استعلام صغيرة، وتتكامل بشكل نظيف مع curl أو HTTPie في تدفق. jq مرخص تحت رخصة MIT ويتم صيانته من قبل المجتمع على github.com/jqlang/jq.

مرر استجابة API مباشرة إليه:

curl -s https://api.github.com/repos/jqlang/jq \
  | jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'

هذا يستخرج ثلاثة حقول من استجابة كبيرة وينشئ كائنًا نظيفًا. الأفضل في: تحويل JSON الصاخب إلى الشكل الذي تحتاجه بالضبط للخطوة التالية في نص برمجي. الحد الصادق هو منحنى التعلم. بناء جملة jq قوي ولكنه موجز، والتحويلات المعقدة يمكن أن تصبح غامضة بسرعة. ومع ذلك، لاستخراج الحقول اليومي، ستتعلم 90% مما تحتاجه في فترة بعد الظهر.

gh: واجهة سطر أوامر GitHub

gh يجلب GitHub إلى الطرفية الخاصة بك: طلبات السحب، المشاكل، الإصدارات، تشغيل Actions، ومكالمات API، كل ذلك دون فتح متصفح. تمت كتابته بلغة Go، مرخص تحت MIT، وموجود على github.com/cli/cli. نظرًا لأن الكثير من عمل واجهات برمجة التطبيقات والعمل الخلفي يعيش في مستودعات GitHub، فإنه ينتمي إلى المجموعة الأساسية.

خدعة مفيدة واحدة: gh api تمنحك غلافًا مصادقًا ومقسمًا لـ GitHub REST و GraphQL APIs، لذلك لا تضطر إلى كتابة الرموز يدويًا في curl.

gh api repos/cli/cli/releases --jq '.[0].tag_name'

هذا يطبع أحدث علامة إصدار باستخدام مرشح jq المدمج في gh. الأفضل في: برمجة GitHub نفسه، من سير عمل CI إلى أتمتة الإصدارات. الحد الصادق هو النطاق؛ إنه مخصص لـ GitHub فقط حسب التصميم. بالنسبة لـ GitLab أو Gitea، ستحتاج إلى واجهات سطر الأوامر الخاصة بهما أو curl عادي ضد واجهات برمجة التطبيقات الخاصة بهما.

Hurl: اختبارات HTTP بنص عادي يمكنك الالتزام بها

Hurl يقوم بتشغيل واختبار طلبات HTTP المعرفة في ملف نص عادي بسيط. تكتب الطلبات، وتؤكد على رموز الحالة، والرؤوس، وأجسام JSON، وتتبع المكالمات عن طريق التقاط القيم من استجابة إلى الأخرى. يحول "اختبار واجهة برمجة التطبيقات" إلى ملف يمكنك تسجيله في Git. Hurl مكتوب بلغة Rust، مرخص تحت Apache 2.0، ويتم صيانته بواسطة Orange على github.com/Orange-OpenSource/hurl.

اكتب ملف .hurl:

GET https://api.github.com/repos/Orange-OpenSource/hurl

HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000

ثم شغله:

hurl --test repo.hurl

يخرج Hurl بالرمز 0 عندما تنجح جميع التأكيدات ورمز غير صفري عندما يفشل أحدها، مما يجعله مناسبًا للدمج مباشرة في CI. الأفضل في: اختبارات التكامل القابلة للقراءة والتحكم في الإصدار والتي يمكن لفريق كامل تحريرها دون تعلم إطار عمل. الحد الصادق هو أنه يركز على اختبار طلب/استجابة HTTP؛ إنه ليس أداة اختبار عقود كاملة أو اختبار حمل. لإلقاء نظرة أوسع على كيفية ملاءمة اختبار CLI لسير عمل تطوير API المعتمد على المواصفات أولاً، يتوافق ملف التأكيد جيدًا مع مصدر OpenAPI للموثوقية.

cloudflared: كشف خادم محلي بدون نفق مدفوع

أحيانًا تحتاج إلى عنوان URL عام لواجهة برمجة التطبيقات التي تعمل على حاسوبك المحمول: رد اتصال webhook، عرض توضيحي، اختبار جوال مقابل مضيف حقيقي. cloudflared هو عميل نفق Cloudflare، ويوفر لك وضع النفق السريع عنوان URL عامًا مؤقتًا *.trycloudflare.com بأمر واحد وبدون حساب. إنه مكتوب بلغة Go، مرخص تحت Apache 2.0، ومفتوح على github.com/cloudflare/cloudflared.

وجهه إلى منفذك المحلي:

cloudflared tunnel --url http://localhost:3000

يطبع عنوان URL عامًا لـ HTTPS يقوم بإعادة التوجيه إلى localhost:3000 حتى توقفه. الأفضل في: أنفاق سريعة ومجانية ومخصصة عندما لا ترغب في التسجيل في أي شيء. إذا كنت تفضل البقاء بالكامل في نظام npm البيئي، فإن localtunnel (MIT) يؤدي نفس المهمة باستخدام npx localtunnel --port 3000. الحد الصادق على الأنفاق السريعة: عنوان URL عشوائي ومؤقت، وبالنسبة للأنفاق المستقرة المسماة، ستقوم بإنشاء حساب Cloudflare وتكوين، على الرغم من أن العميل يظل مفتوح المصدر في كلتا الحالتين.

git: التحكم في الإصدار كواجهة سطر أوامر، وليس واجهة رسومية

من السهل أن ننسى أن Git هي أداة سطر أوامر في المقام الأول. كل مواصفات API، وملف اختبار، وسيناريو Hurl المذكور أعلاه ينتمي إلى مستودع Git، وواجهة سطر الأوامر هي حيث تكمن القوة الحقيقية: التحديد الدقيق للمرحلة (staging)، bisect، rebase، والمخطافات (hooks) التي تشغل اختبارات API الخاصة بك قبل تسجيل التزام (commit). Git مرخص تحت GPLv2 ويتم تطويره بشكل مفتوح على github.com/git/git.

مثال صغير يربط المجموعة معًا: مخطط ما قبل الالتزام (pre-commit hook) يقوم بتشغيل اختبارات Hurl الخاصة بك قبل تسجيل الكود.

echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

الأفضل في: أن يكون الركيزة التي يستند إليها كل شيء آخر. مستضاف ذاتيًا منذ اليوم الأول، لا يتطلب خادمًا، وقابل للتطوير (forgeable) بكل معنى الكلمة. الحد الصادق هو أن Git هو نظام للتحكم في الإصدارات، وليس استضافة مشاريع؛ طبقة الاستضافة (GitHub، GitLab، Gitea) هي اختيار منفصل، وبعضها فقط مفتوح المصدر بنفسه.

ملاحظة صادقة: أين تتناسب Apidog

Apidog ليس مفتوح المصدر، لذا فهو لا ينتمي إلى هذه القائمة كإدخال OSS. إنه منتج تجاري ذو طبقة مجانية، ويستحق الذكر هنا لسبب واحد: الأدوات المذكورة أعلاه ممتازة بشكل فردي، لكنك في النهاية تقوم بتجميعها يدويًا. curl للطلبات، jq للتحليل، Hurl للاختبارات، خادم وهمي منفصل، مولد وثائق، متغيرات بيئة مدارة في ملفات تعريف الصدفة.

Apidog يجمع التصميم والاختبار والمحاكاة والتوثيق في مساحة عمل واحدة، وapidog-cli يجلب ذلك إلى الطرفية. إنها حزمة npm (npm install -g apidog-cli)، وهي تشغل سيناريوهات الاختبار، وتدير نقاط النهاية والمخططات، وتدور توقعات المحاكاة، وتستورد أو تصدر OpenAPI، كل ذلك مع إخراج JSON منظم يمكن للبرامج النصية ووكلاء الذكاء الاصطناعي قراءته. apidog run يخرج بالرمز 0 عند النجاح الكامل ورمز غير صفري عند الفشل، لذلك يندمج في CI بنفس طريقة Hurl.

التأطير الصادق: إذا كنت تريد عدم الارتباط (lock-in) والوصول الكامل إلى المصدر، فإن مجموعة الأدوات مفتوحة المصدر هي الخيار الصحيح، وهذا ما يدور حوله هذا المقال. إذا كنت تفضل عدم تجميع سبع أدوات معًا وصيانة البنية التحتية بنفسك، فإن الطبقة المجانية من Apidog بالإضافة إلى واجهة سطر الأوامر الخاصة به تمنحك بديلاً متكاملاً. كلاهما صالح؛ إنهما يحسنان أشياء مختلفة. إذا اخترت مسار واجهة سطر الأوامر، فإن دليل التثبيت يشرح المصادقة والأوامر الأولى.

كيف تختار

طابق الأداة مع المهمة. معظم المطورين يشغلون عدة من هذه الأدوات معًا، curl أو HTTPie لجلب البيانات، jq للتحليل، Hurl للاختبار، git للتحكم في إصدار كل شيء.

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

الخلاصة

تكتسب المصادر المفتوحة مكانها في الطرفية لكونها قابلة للفحص، وقابلة للاستضافة الذاتية، وخالية من الارتباط. تغطي أدوات curl وHTTPie وjq وgh وHurl وcloudflared وgit جوهر تطوير واجهات برمجة التطبيقات والعمل الخلفي، وكل واحدة منها هي ترخيص يمكنك قراءته ومستودع يمكنك تفريعه. ابدأ بالأدوات الاثنين أو الثلاثة التي تناسب سير عملك الحالي وأضف البقية حسب حاجتك.

إذا كنت تبني مهام سير عمل تعتمد على الوكيل (agent-driven workflows) فوق هذه الأدوات، فإن نفس مبادئ "الطرفية أولاً" تنطبق، ويصبح إخراج JSON المنظم هو النسيج الرابط؛ يتعمق مقال مساعدي الذكاء الاصطناعي في تطوير واجهات برمجة التطبيقات في هذا الجانب. وإذا بدأت صيانة سبع أدوات منفصلة تبدو وكأنها مهمة بحد ذاتها، قم بتنزيل Apidog وجرب Apidog CLI لترى كيف يبدو المسار المتكامل قبل الالتزام بأي من الخيارين.