أفضل أدوات CLI خفيفة لاختبار API

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

الخفة هنا تعني شيئًا محددًا. تثبيت صغير، غالبًا ما يكون ملفًا تنفيذيًا واحدًا (binary) أو أمر npx سريعًا. بدء تشغيل سريع، بحيث تشعر أن الوصول إلى نقطة نهاية فوري. القليل من التكوين أو عدم وجوده لتشغيل الطلب الأول. مخرجات موجهة للمحطة الطرفية (terminal-first) يمكنك توجيهها إلى jq أو grep. هذا سؤال مختلف عن "أي أداة مفتوحة المصدر" أو "أيها تحتوي على معظم الميزات". إنه يتعلق بالبصمة والاحتكاك. للحصول على مسح أوسع يغطي أيضًا واجهات المستخدم الرسومية المستضافة (hosted GUIs)، انظر ملخص أفضل أدوات اختبار API المجانية.

توجد أدناه ثماني أدوات CLI خفيفة الوزن لاختبار واجهات برمجة تطبيقات REST و HTTP، مرتبة تقريبًا من الأصغر والأكثر يدوية إلى تلك التي تشغل مجموعات اختبار كاملة في CI. يحتوي كل إدخال على أمر تثبيت حقيقي، وأمر واحد يوضح طريقة عمله، وما هو الأفضل فيه، وحدود صادقة. الأخير، Apidog CLI، هو الملف التنفيذي الخفيف الذي يقوم بتشغيل السيناريوهات التي تبنيها بصريًا ويتحكم في مسار العمل (pipeline) بناءً على رمز الخروج الخاص به.

ما الذي يجعل أداة CLI "خفيفة الوزن" لاختبار API؟

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

• بصمة صغيرة. ملف تنفيذي واحد (single binary)، أو تثبيت pip/npm، أو أمر npx من سطر واحد. لا بيئة تشغيل (runtime) تحتاج إلى إعدادها أولاً، ومن الأفضل ألا يكون هناك برنامج خفي (daemon).
• بدء تشغيل سريع. الأداة تعمل وترسل الطلب دون تسخين. تفوز الملفات التنفيذية المكتوبة بلغة Rust و Go هنا؛ وأي شيء يشغل بيئة تشغيل ثقيلة يخسر.
• تكوين قليل أو معدوم. يمكنك إرسال الطلب الأول دون ملف مشروع، أو حساب، أو تسجيل دخول. التكوين اختياري، عندما تريد الحفظ والتكرار.
• مخرجات أصلية للمحطة الطرفية. تطبع النتائج بشكل يمكنك قراءته بسرعة وتوجيهه إلى أمر آخر. رموز الخروج تعني شيئًا، لذا يمكن لـ CI أن يتحكم فيها.

الأدوات الرائدة تبدأ بالنقاط الثلاث الأولى؛ بينما تتوجه النقطتان الأخيرتان إلى النقطة الرابعة، لأن هذا هو المكان الذي يكسب فيه الملف التنفيذي الخفيف مكانه في خط الأنابيب (pipeline). إذا كنت تريد الجانب التفاعلي، وهو "الوصول إلى نقطة نهاية يدويًا" بشكل أعمق، فإن دليل بدائل curl لاختبار REST API يتعمق في العملاء اليدويين.

curl: الأساس المثبت بالفعل

curl هي الأداة التي لديك بالفعل على الأرجح. تأتي مثبتة مسبقًا على macOS، ومعظم توزيعات Linux، و Windows الحديثة، لذا فإن أخف تثبيت هو عدم التثبيت. تتحدث بروتوكولات HTTP و HTTPS وقائمة طويلة من البروتوكولات الأخرى، وهي المرجع الذي تقيس جميع العملاء الأخرى نفسها به.

# Already on your machine; check the version
curl --version

# POST JSON and print only the HTTP status
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'

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

HTTPie: curl للبشر

يقوم HTTPie بنفس الطلبات التي يقوم بها curl، ولكن بتركيب مصمم للبشر. الأمر هو http، والرؤوس وحقول JSON هي أزواج بسيطة من key=value، والمخرجات ملونة ومنسقة افتراضيًا. إنه مكتوب بلغة Python، لذا يتطلب بيئة تشغيل Python، مما يجعله أثقل من ملف تنفيذي واحد ولكنه لا يزال تثبيتًا بسطر واحد.

python -m pip install httpie   # or: brew install httpie

# POST JSON: age:=24 sends a number, name= sends a string
http POST httpbin.org/post name=acme age:=24 plan=pro

الأفضل لـ: استكشاف API يدويًا عندما تريد مخرجات قابلة للقراءة بدون استخدام علامات (flags). حدها الصادق: بدء تشغيل Python أبطأ بشكل ملحوظ من الملف التنفيذي المترجم، والتثبيت على نظام نظيف يعني سحب Python إذا لم يكن موجودًا. مثل curl، هو عميل وليس أداة تشغيل اختبار؛ أنت تقرأ الاستجابة، ولا تؤكد عليها.

xh: سرعة HTTPie في ملف تنفيذي واحد

يعيد xh تنفيذ تركيب HTTPie الودود بلغة Rust ويأتي كملف تنفيذي واحد مرتبط بشكل ثابت. تحصل على نفس سهولة استخدام key=value والمخرجات الملونة، مع بدء تشغيل أسرع ولا شيء لتثبيته بخلاف الملف التنفيذي نفسه. يدعم HTTP/2 ويمكنه حتى طباعة أمر curl المكافئ باستخدام --curl.

brew install xh   # or: cargo install xh --locked

# Same syntax as HTTPie, faster start
xh POST httpbin.org/post name=acme age:=24 plan=pro

الأفضل لـ: المطورين الذين يحبون إحساس HTTPie ولكنهم يريدون ملفًا تنفيذيًا واحدًا سريعًا بدون بيئة تشغيل. حدها الصادق: لا تنفذ كل ميزات HTTPie، ولا يوجد نظام إضافات (plugin system). إنها أحدث من HTTPie، لذا فإن النظام البيئي المحيط بها أصغر. لا تزال عميلاً، وليست محرك تأكيد.

Hurl: اختبارات نصية بسيطة تعمل في CI

Hurl هو المكان الذي تتجاوز فيه هذه القائمة من "إرسال طلب" إلى "اختبار استجابة". إنه يقوم بتشغيل طلبات HTTP مكتوبة في ملف نصي بسيط .hurl ويؤكد على النتائج. إنه مكتوب بلغة Rust، ويُشغل بواسطة libcurl في الخلفية، ويأتي كملف تنفيذي واحد بدون بيئة تشغيل. تُقرأ الاختبارات تقريبًا مثل الطلبات نفسها، مما يجعل مراجعتها سهلة في طلب السحب (pull request).

brew install hurl   # or: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

hurl --test login.hurl   # non-zero exit if an assertion fails

الأفضل لـ: فحوصات نمط العقود واختبارات السلامة (smoke tests) التي تحتفظ بها في التحكم بالإصدار كنص قابل للقراءة. تجعل علامة --test منه بوابة CI نظيفة؛ يؤدي فشل التأكيد إلى إرجاع رمز خروج غير صفري. حدها الصادق: إنها تركز على HTTP، لذا لن تقوم بتشغيل gRPC أو توليد حمل حقيقي. تعني التدفقات المعقدة المزيد من ملفات .hurl بدلاً من لغة برمجة نصية.

Step CI: ملف YAML واحد لتدفق متعدد الخطوات

يشغل Step CI تدفقات عمل API الموصوفة في ملف YAML واحد. يغطي REST و GraphQL و gRPC و tRPC و SOAP في تدفق عمل واحد، ويمكنه التحقق من صحتها مقابل مخطط OpenAPI. يمكنك تثبيته من npm وتشغيل نفس الملف محليًا وفي CI. يُقرأ جيدًا عندما يكون الاختبار في الواقع تسلسلاً: تسجيل الدخول، التقاط رمز، استخدامه في المكالمة التالية، التحقق من النتيجة.

npm install -g stepci

# workflow.yml describes steps, captures, and checks
stepci run workflow.yml

الأفضل لـ: الفرق التي تريد ملفًا تصريحيًا واحدًا يصف تدفق API متعدد الخطوات، يُشغل بشكل متطابق على جهاز كمبيوتر محمول وفي مسار العمل (pipeline). حدها الصادق: إنها حزمة Node، لذا فهي أثقل من الملفات التنفيذية المكتوبة بلغة Rust أو Go، وتحمل بيئة تشغيل. تباطأت وتيرة الإصدارات، لذا تحقق من النشاط الأخير للمستودع (repo) قبل بناء مسار عمل عليها. لمعرفة كيف تتناسب هذه الأجزاء مع خطة اختبار أكثر اكتمالاً، انظر استراتيجيات اختبار API.

k6: اختبار الحمل الخفيف من المحطة الطرفية

يجيب k6 على سؤال مختلف: ليس "هل هذه الاستجابة صحيحة" بل "هل تصمد تحت الحمل". إنه مكتوب بلغة Go، ويأتي كملف تنفيذي ثابت واحد، والسكريبتات هي JavaScript عادية. إنه مصمم للاستخدام الأدنى للموارد، بحيث يمكنك دفع حركة مرور حقيقية من جهاز كمبيوتر محمول. تتحول الحدود القصوى (Thresholds) لاختبار الحمل إلى بوابة نجاح/فشل؛ عند تجاوز أحدها، يخرج k6 برمز 99، والذي تقرأه مسار العمل (pipeline) على أنه فشل.

brew install k6   # or run via Docker: docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
  vus: 10, duration: '30s',
  thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
  const res = http.get('https://httpbin.org/get');
  check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF

k6 run load.js

الأفضل لـ: فحوصات الأداء والحمل التي تريد برمجتها وتشغيلها في CI دون إعداد مجموعة (cluster). حدها الصادق: إنها أداة حمل، وليست عميل اختبار وظيفي؛ لن تلجأ إليها لفحص استجابة واحدة يدويًا. تتطلب كتابة سيناريوهات ذات معنى تعلم واجهة برمجة تطبيقات JavaScript الخاصة بها.

Newman: تشغيل مجموعة Postman بدون واجهة رسومية

Newman هو أداة تشغيل سطر الأوامر لمجموعات Postman. إذا كان فريقك يقوم بالفعل ببناء الطلبات والاختبارات في Postman، فإن Newman يشغل هذه المجموعة بالضبط من المحطة الطرفية بدون واجهة رسومية، وهو ما تحتاجه في CI. تقوم بتصدير المجموعة (وباختيارك بيئة) كـ JSON وتوجه Newman إليها.

npm install -g newman

# collection.json exported from Postman; -e passes an environment
newman run collection.json -e staging.json

الأفضل لـ: الفرق المستثمرة في Postman والتي تريد تشغيل مجموعاتها الحالية بدون واجهة رسومية في مسار العمل (pipeline). يعيد Newman رمز خروج غير صفري عندما يفشل الاختبار، لذا فإنه يغلق CI بشكل نظيف. حدها الصادق: إنها حزمة Node، وتشغل فقط مجموعات بتنسيق Postman، لذا فهي الأكثر فائدة إذا كنت بالفعل في هذا النظام البيئي. إنها تشغل اختبارات قام شخص ما ببنائها في واجهة رسومية؛ وما يزال التأليف يحدث هناك.

Apidog CLI: تشغيل السيناريوهات التي أنشأتها، والتحكم في CI بناءً على رمز الخروج

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

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

لا تخمن معرفات السيناريو والبيئة. افتح سيناريو الاختبار الخاص بك في Apidog، انتقل إلى علامة تبويب CI/CD، وانسخ أمر apidog run الذي تم إنشاؤه مع المعرفات المملوءة بالفعل. يقوم تقرير -r cli بطباعة نتيجة خطوة بخطوة وملخص في المحطة الطرفية؛ أضف -r cli,junit عندما تحتاج لوحة تحكم CI إلى تحليل النتائج. مثل الأدوات المذكورة أعلاه، يخرج apidog run برمز 0 عندما تنجح جميع التأكيدات ورمز غير صفري عندما يفشل أي شيء، لذا فإن مسار العمل (pipeline) يعامله كبوابة نظيفة. إخراجه هو JSON منظم مع agentHints.nextSteps، مما يجعله سهلاً لوكيل ترميز AI لتشغيله وقراءته أيضًا.

الأفضل لـ: الفرق التي تريد تأليف سيناريوهات معقدة ومتعددة الخطوات في محرر مرئي ولكن تشغيلها بدون واجهة رسومية في CI أو من وكيل. حدها الصادق: على عكس curl أو xh، فهي مرتبطة بالسيناريوهات التي تحتفظ بها في مشروع Apidog، لذا فهي خيار المنصة المتكاملة، وليست عميل HTTP عاديًا. للاطلاع على مجموعة الأوامر الكاملة، انظر الدليل الكامل لـ Apidog CLI، و مرجع أمر apidog run، ودليل كيفية اختبار REST API من سطر الأوامر باستخدام Apidog CLI.

كيف تختار

تعتمد الأداة المناسبة على مدى تجاوزك لـ "إرسال طلب واحد".

ابدأ من الأعلى للعمل اليدوي. استخدم curl أو xh للتعامل مع نقطة نهاية. انتقل إلى Hurl عندما تريد تشغيل هذه الفحوصات في التحكم بالإصدار. استخدم k6 عندما يتحول السؤال إلى الحمل، و Newman إذا كانت اختباراتك موجودة بالفعل في Postman. اختر Apidog CLI عندما تفضل بناء سيناريو معقد في محرر وتشغيله بدون واجهة رسومية في أي مكان آخر. إذا كنت تقارن هذه الأدوات بسير عمل كامل بدون واجهة رسومية، فإن دليل أدوات اختبار API بدون واجهة رسومية يغطي تشغيل الاختبارات بدون أي واجهة على الإطلاق.

أين تؤتي الأدوات الخفيفة ثمارها

تفوز أدوات CLI الخفيفة في نفس الأيام التي تبطئك فيها واجهة المستخدم الرسومية (GUI): عندما تكون منغمسًا في محطة طرفية، عندما يحتاج الاختبار إلى التشغيل في CI بدون تدخل بشري، وبشكل متزايد عندما يقوم وكيل AI بتشغيل الفحص نيابةً عنك. يحافظ curl و xh على حلقة العمل اليدوي محكمة. يحول Hurl و Step CI الطلبات المخصصة إلى اختبارات قابلة للتكرار. يجيب k6 على سؤال الحمل. يشغل Newman ما بنيته بالفعل في Postman.

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