لا تزال الطرفية (Terminal) مركزًا لمعظم مهام المطورين، خصوصًا في تطوير الواجهات الخلفية وواجهات برمجة التطبيقات. الأدوات التي تبقى مفيدة لسنوات تشترك غالبًا في ميزة مهمة: أنها مفتوحة المصدر، ويمكنك قراءة كودها، وتشغيلها محليًا أو استضافتها ذاتيًا، وتفريعها إذا توقف المشروع عن الصيانة. عند اختيار أدوات لسير عمل تطوير واجهات برمجة التطبيقات (API)، افحص الترخيص والمستودع وسجل الصيانة قبل أي شيء آخر.
ستبني في هذا المقال مجموعة أدوات عملية تغطي دورة العمل الأساسية: إرسال طلبات HTTP، تحليل JSON، اختبار التدفقات، أتمتة GitHub، كشف خادم محلي للإنترنت، وإصدار الكود. لكل أداة ستجد الترخيص والمستودع ومثالًا قابلًا للتشغيل مباشرة.
ما الذي يجعل أداة CLI مفتوحة المصدر فعلًا؟
ليست كل أداة مجانية أداة مفتوحة المصدر. استخدم هذه القائمة للتحقق قبل اعتماد أي أداة في مشروعك:
تحقق من الترخيص
ابحث عن ترخيص معتمد من OSI مثل MIT أو Apache 2.0 أو BSD أو GPL. هذه التراخيص تتيح لك الاستخدام والتعديل والاستضافة الذاتية ضمن شروطها.تحقق من المصدر وسجل الصيانة
يجب أن يكون المصدر متاحًا على GitHub أو منصة مكافئة. راجع ملفLICENSE، والإصدارات، والمشاكل المفتوحة، وسجل الالتزامات.تجنب الارتباط الإجباري
لا ينبغي أن تتطلب الأداة حسابًا أو خادمًا مستأجرًا لتعمل في السيناريو الأساسي. إذا كانت تعتمد على خدمة، فاعرف ما إذا كان يمكنك تشغيل المكونات بنفسك.
النجوم ليست معيارًا كافيًا. أداة هادئة ومستقرة بترخيص MIT أو Apache قد تكون خيارًا أفضل من أداة شائعة تقيّد الاستخدام التجاري أو تمنع الاستضافة الذاتية.
curl: عميل HTTP الأساسي
تُعد curl نقطة البداية لمعظم عمليات HTTP في الطرفية. تدعم بروتوكولات عديدة، وتأتي مثبتة مسبقًا في معظم الأنظمة، وتناسب السكربتات وبيئات CI. وهي مرخصة تحت ترخيص curl المتساهل، ومصدرها متاح على github.com/curl/curl.
أرسل طلب POST مصادقًا
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"}'
استخدم curl عندما تحتاج إلى:
- أمر متاح تقريبًا في كل بيئة.
- طلبات قابلة للتشغيل داخل shell scripts.
- تنفيذ سريع في CI/CD.
- تحكم كامل في الرؤوس والجسم وطرق الطلب.
القيد العملي: إخراج curl خام، لذلك ستحتاج غالبًا إلى jq لتحليل JSON.
HTTPie: طلبات HTTP مقروءة أثناء التصحيح
يوفر HTTPie صياغة أبسط للطلبات التفاعلية. الطلبات مقروءة، وأجسام JSON تُنشأ تلقائيًا، والاستجابة تظهر منسقة وملونة. الأداة مرخصة تحت BSD-3-Clause، ومصدرها موجود على github.com/httpie/cli.
التثبيت والاستخدام
pip install httpie
http POST httpbin.org/post name=apidog role=platform
في هذا المثال، تتحول القيم:
name=apidog
role=platform
إلى جسم JSON تلقائيًا. استخدم HTTPie عند استكشاف API أو تصحيح طلب يدويًا، خصوصًا عندما تريد رؤية الاستجابة بشكل واضح دون إضافة خيارات كثيرة.
القيد العملي: يعتمد على Python، لذلك قد يكون curl أخف في صور CI الصغيرة أو الحاويات محدودة الحجم.
jq: استخرج البيانات التي تحتاجها من JSON
تعيد معظم APIs بيانات JSON، و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}'
بدلًا من التعامل مع الاستجابة كاملة، ستحصل على كائن صغير بالشكل الذي تحتاجه:
{
"name": "jq",
"stars": 0,
"license": "MIT"
}
قيمة
starsفي المثال تعتمد على وقت تشغيل الطلب.
استخدم jq في خطوط الأنابيب:
curl -s https://api.github.com/repos/jqlang/jq \
| jq -r '.html_url'
القيد العملي: صياغة jq مختصرة وقوية، وقد تصبح التحويلات المعقدة صعبة القراءة. لكن لاستخراج الحقول والتصفية اليومية، ستغطي الأساسيات معظم احتياجاتك.
gh: أتمتة GitHub من الطرفية
تجلب gh عمليات GitHub إلى الطرفية: المشاكل، وطلبات السحب، والإصدارات، وGitHub Actions، وREST وGraphQL APIs. الأداة مكتوبة بلغة Go، ومرخصة تحت MIT، ومصدرها على github.com/cli/cli.
اجلب أحدث إصدار لمستودع
gh api repos/cli/cli/releases --jq '.[0].tag_name'
يستخدم هذا الأمر مصادقة gh الحالية، لذلك لا تحتاج إلى تمرير رمز وصول يدويًا كما تفعل عادة مع curl.
استخدم gh عندما تحتاج إلى:
- إنشاء أو إدارة issues وpull requests.
- تشغيل أو فحص GitHub Actions.
- استدعاء GitHub API من سكربتات الإصدار.
- تنفيذ أتمتة مرتبطة بالمستودعات.
القيد العملي: الأداة مخصصة لـ GitHub فقط. للتعامل مع GitLab أو Gitea، استخدم الواجهة الخاصة بهما أو curl مباشرة ضد API.
Hurl: اختبارات HTTP قابلة للحفظ في Git
تتيح لك Hurl تعريف طلبات HTTP واختباراتها في ملفات نصية بسيطة. يمكنك تأكيد رموز الحالة والرؤوس ومسارات JSON، ثم حفظ هذه الملفات بجانب كود التطبيق. Hurl مكتوبة بلغة Rust، ومرخصة تحت Apache 2.0، ومصدرها على github.com/Orange-OpenSource/hurl.
أنشئ اختبارًا في ملف repo.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:
hurl --test tests/*.hurl
استخدم Hurl لاختبارات التكامل القابلة للمراجعة داخل pull requests. وهو مناسب عندما تريد ملفات اختبار بسيطة يمكن للفريق قراءتها وتعديلها دون إطار اختبار كامل.
القيد العملي: يركز Hurl على اختبار تدفقات HTTP، وليس بديلًا كاملًا لاختبار العقود أو اختبار الحمل. إذا كنت تعمل ضمن سير عمل تطوير API المعتمد على المواصفات أولًا، فحافظ على OpenAPI كمصدر موثوق وأضف ملفات Hurl لاختبار السلوك الفعلي.
cloudflared: اكشف خادمك المحلي بعنوان عام
عند اختبار webhooks أو تطبيقات الجوال أو العروض التوضيحية، تحتاج أحيانًا إلى عنوان HTTPS عام يشير إلى خادم يعمل محليًا. يوفر cloudflared وضع نفق سريع ينشئ عنوانًا مؤقتًا من نطاق trycloudflare.com دون حساب. الأداة مكتوبة بلغة Go، ومرخصة تحت Apache 2.0، ومصدرها على github.com/cloudflare/cloudflared.
اكشف خادمًا يعمل على المنفذ 3000
cloudflared tunnel --url http://localhost:3000
سيطبع الأمر عنوان HTTPS عامًا يعيد التوجيه إلى:
http://localhost:3000
استخدمه لتسجيل عنوان webhook مؤقتًا أو لمشاركة نسخة تطوير مع شخص آخر.
إذا كنت تفضل بيئة npm، فإن localtunnel المرخصة تحت MIT توفر بديلًا مشابهًا:
npx localtunnel --port 3000
القيد العملي: عناوين النفق السريع عشوائية ومؤقتة. للحصول على نفق ثابت باسم مخصص، ستحتاج إلى إعداد حساب Cloudflare وتكوين إضافي، رغم أن العميل نفسه يظل مفتوح المصدر.
git: اجعل اختبارات API جزءًا من تاريخ المشروع
Git ليس مجرد خلفية لواجهة رسومية؛ واجهة سطر الأوامر هي المكان الذي تستخدم فيه rebase وbisect وhooks والتحكم الدقيق في staging. كل ملف OpenAPI، واختبار Hurl، وسكربت curl يجب أن يعيش في مستودع Git. Git مرخص تحت GPLv2 ومصدره على github.com/git/git.
شغّل اختبارات Hurl قبل كل commit
أنشئ hook محليًا:
echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
الآن، سيفشل git commit إذا فشل أحد اختبارات Hurl.
ملاحظة: ملفات hooks داخل
.git/hooksلا تُشارك تلقائيًا مع الفريق. إذا أردت توحيدها، احتفظ بسكربتات hooks في المستودع واضبطcore.hooksPathداخل إعدادات المشروع.
القيد العملي: Git نظام تحكم في الإصدارات، وليس منصة استضافة. اختيار GitHub أو GitLab أو Gitea هو قرار منفصل.
ملاحظة صادقة: أين تتناسب Apidog؟
Apidog ليس مفتوح المصدر، لذلك لا ينتمي إلى قائمة أدوات OSS. إنه منتج تجاري يوفّر طبقة مجانية. الفرق العملي هو أن الأدوات السابقة تؤدي مهامًا متخصصة، بينما تحتاج أنت إلى تجميعها وإدارة إعداداتها: curl للطلبات، وjq للبيانات، وHurl للاختبارات، وأدوات منفصلة للمحاكاة والتوثيق والمتغيرات.
يجمع Apidog التصميم والاختبار والمحاكاة والتوثيق في مساحة عمل واحدة. كما تنقل apidog-cli أجزاء من هذا التدفق إلى الطرفية.
npm install -g apidog-cli
بحسب سير العمل المستخدم، يمكن لـ apidog-cli تشغيل سيناريوهات الاختبار وإدارة نقاط النهاية والمخططات وتوقعات المحاكاة واستيراد أو تصدير OpenAPI، مع إخراج JSON منظم مناسب للسكربتات ووكلاء الذكاء الاصطناعي. كما أن apidog run يعيد الرمز 0 عند النجاح ورمزًا غير صفري عند الفشل، ما يجعله مناسبًا لـ CI مثل Hurl.
الاختيار هنا واضح:
- اختر أدوات OSS المتخصصة إذا كانت الأولوية للتحكم الكامل والوصول إلى المصدر وتقليل الارتباط.
- اختر منصة متكاملة إذا أردت تقليل عدد الأدوات والبنية التحتية التي تديرها.
إذا اخترت مسار CLI، راجع دليل تثبيت Apidog CLI لمعرفة خطوات المصادقة والأوامر الأولى.
كيف تختار الأداة المناسبة؟
استخدم عدة أدوات معًا بدل البحث عن أداة واحدة لكل شيء:
| الأداة | الأفضل لـ | التثبيت | مفتوحة المصدر؟ | ملاحظات |
|---|---|---|---|---|
| curl | طلبات محمولة وسكربتات | مثبتة مسبقًا غالبًا | نعم (curl/نوع MIT) | متاحة في معظم الأنظمة |
| HTTPie | تصحيح أخطاء تفاعلي | pip install httpie |
نعم (BSD-3-Clause) | JSON وإخراج ملون |
| jq | تحليل استجابات JSON | مدير حزم أو ثنائي | نعم (MIT) | أساسية لخطوط الأنابيب |
| gh | أتمتة GitHub | مدير حزم أو ثنائي | نعم (MIT) | مخصصة لـ GitHub |
| Hurl | اختبارات HTTP قابلة للإصدار | ثنائي واحد | نعم (Apache 2.0) | رمز خروج غير صفري عند الفشل |
| cloudflared | أنفاق عامة مؤقتة | ثنائي واحد | نعم (Apache 2.0) | النفق السريع لا يحتاج حسابًا |
| git | التحكم في الإصدارات | مثبتة مسبقًا غالبًا | نعم (GPLv2) | أساس بقية الأدوات |
| apidog-cli | سير عمل API متكامل | npm i -g apidog-cli |
لا، طبقة مجانية | تصميم واختبار ومحاكاة وتوثيق |
القاعدة العملية:
- استخدم أداة مفتوحة المصدر ذات غرض واحد عندما تحتاج إلى تحكم دقيق في البنية التحتية.
- استخدم منصة متكاملة عندما تكون تكلفة تجميع وصيانة الأدوات المتعددة أعلى من فائدتها.
لمقارنة المسار المتكامل، يشرح مقال Apidog كمنصة شاملة لتطوير واجهات برمجة التطبيقات المهام التي يمكن أن يجمعها هذا النهج في مكان واحد.
الخلاصة
تمنحك أدوات curl وHTTPie وjq وgh وHurl وcloudflared وGit مجموعة عملية ومفتوحة المصدر لتطوير APIs والعمل الخلفي. ابدأ بالحد الأدنى:
- استخدم
curlأو HTTPie لإرسال الطلبات. - أضف
jqلمعالجة JSON. - أضف Hurl عندما تحتاج إلى اختبارات قابلة للتشغيل في CI.
- احفظ المواصفات والاختبارات والسكريبتات في Git.
- استخدم
cloudflaredعندما تحتاج إلى URL عام لخادمك المحلي.
إذا كنت تبني تدفقات عمل تعتمد على الوكلاء، فاجعل مخرجات أدواتك منظمة وقابلة للقراءة آليًا، خصوصًا JSON. لمزيد من التفاصيل، راجع مقال مساعدي الذكاء الاصطناعي في تطوير واجهات برمجة التطبيقات.
وإذا أصبحت صيانة أدوات متعددة عبئًا بحد ذاتها، يمكنك تنزيل Apidog وتجربة Apidog CLI قبل اتخاذ قرار بين المسار المتكامل ومجموعة الأدوات المفتوحة المصدر.





Top comments (0)