ما هو اختبار API؟ وكيف تختبر REST API

ما الذي يغطيه اختبار API

«اختبار API» عائلة من الفحوصات لا نشاط واحد. تنفّذ معظم الفرق الأنواع الثلاثة الأولى مع كل تغيير والبقية قبل كل إصدار.

• الاختبار الوظيفي — هل تعيد كل نقطة نهاية الاستجابة الصحيحة للمدخلات الصالحة؟ هل ينشئ POST السجل، وهل يعيده GET، وهل يحذفه DELETE؟
• اختبار التحقق والاختبار السلبي — ماذا يحدث مع الحقول الناقصة، أو الأنواع الخاطئة، أو القيم خارج النطاق، أو JSON مشوّه، أو رمز منتهي الصلاحية، أو طلب كبير جداً؟ يجب أن تجيب الواجهة بخطأ 4xx واضح، ولا تعيد 500 أبداً.
• اختبار العقد — هل ما زالت الاستجابة تطابق المخطط المتفق عليه (OpenAPI أو JSON Schema)؟ الحقول المحذوفة والأنواع المتغيّرة تعطّل كل المستهلكين.
• المصادقة والتفويض — هل ترفض نقاط النهاية المحمية الطلبات المجهولة (401) والطلبات من المستخدم أو الدور الخطأ (403)؟
• الأداء — كم يستغرق الطلب، وما حجم الحمولة، وكيف تتصرف نقطة النهاية تحت حمل متزامن؟
• الأمان — الترويسات، والحقن في معاملات الاستعلام والأجسام، وتحديد المعدل، وما إذا كانت استجابات الأخطاء تسرّب تتبّع المكدس أو التفاصيل الداخلية.

تشريح الطلب والاستجابة

لكل تبادل HTTP الأجزاء نفسها، وكل جزء منها شيء يمكن التحقق منه.

• الطريقة (Method) — GET يقرأ، وPOST ينشئ، وPUT يستبدل، وPATCH يعدّل جزءاً من المورد، وDELETE يحذف. استخدام الطريقة الخاطئة خطأ بحد ذاته.
• عنوان URL وسلسلة الاستعلام — مسار المورد (‎/orders/42) مع المرشّحات والتصفّح (‎?status=paid&page=2).
• ترويسات الطلب — Content-Type تخبر الخادم بما ترسله، وAccept بما تتوقعه، وAuthorization بمن أنت.
• جسم الطلب — عادةً JSON في REST؛ ويجب أن يطابق المخطط الموثّق.
• رمز الحالة — 2xx نجاح، و3xx إعادة توجيه، و4xx خطأ من العميل، و5xx فشل في الخادم. الرمز الدقيق مهم: 201 للإنشاء، و204 لعدم وجود محتوى، و400 للمدخلات السيئة، و404 لغير الموجود، و409 للتعارض، و422 لأخطاء التحقق.
• ترويسات الاستجابة — Content-Type، والتخزين المؤقت، وعدّادات تحديد المعدل، وترويسات CORS والأمان.
• جسم الاستجابة — البيانات، أو كائن خطأ متسق برمز قابل للقراءة آلياً ورسالة مفهومة للبشر.

POST /api/v1/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"customerId": 7, "items": [{"sku": "A-100", "qty": 2}]}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/orders/9021

{"id": 9021, "status": "pending", "total": 249.90}

جرّبها: منشئ طلبات API

كيف تختبر REST API خطوة بخطوة

• اقرأ العقد أولاً. افتح مستند OpenAPI/Swagger أو توثيق الواجهة وأعدّ قائمة بكل نقطة نهاية ومعاملاتها واستجابة النجاح وكل خطأ موثّق.
• أرسل المسار السعيد. لكل نقطة نهاية أرسل طلباً صالحاً وتحقق من رمز الحالة ومخطط الاستجابة والقيم الأساسية. احفظ الاستجابة — فهي خط الأساس لديك.
• اكسر المدخلات عمداً. احذف الحقول المطلوبة، وأرسل النوع الخاطئ، وتجاوز الأطوال، واستخدم القيم الحدّية (0 و-1 والحد الأقصى + 1)، وأرسل أجساماً فارغة وضخمة، وأرسل JSON مشوّهاً. توقّع رموز 4xx دقيقة ورسائل خطأ تسمّي المشكلة.
• اختبر المصادقة. استدعِ نقاط النهاية المحمية دون رمز، وبرمز منتهي الصلاحية، وبرمز لمستخدم آخر، وبرمز بنطاق خاطئ. توقّع 401 أو 403، ولا تتوقع بيانات أبداً.
• تحقق من تغيّر الحالة. بعد POST نفّذ GET على المورد وتأكد من وجوده؛ وبعد DELETE تأكد من اختفائه؛ وبعد PUT تأكد من تغيّر كل حقل وعدم تغيّر أي شيء آخر.
• تحقق من الترويسات لا من الأجسام فقط. يجب أن يكون Content-Type هو application/json، وأن يكون التخزين المؤقت صحيحاً للبيانات الخاصة، وأن يكون CORS مناسباً لعملاء المتصفح.
• قِس. سجّل زمن استجابة كل استدعاء؛ فأي زمن يتصاعد بين الإصدارات هو انحدار حتى لو كان «يعمل».
• أتمت ما كرّرته. حوّل الطلبات والتحققات إلى مجموعة أو سكربت يعمل مع كل بناء.

جرّبها: مختبِر REST API جرّبها: مختبِر نقاط نهاية API جرّبها: مختبِر مصادقة API

ما الذي تتحقق منه في كل استجابة

• رمز الحالة هو بالضبط الرمز الموثّق.
• ترويسة Content-Type صحيحة والجسم قابل للتحليل.
• الجسم يطابق المخطط: الحقول المطلوبة موجودة، والأنواع صحيحة، ولا حقول غير متوقعة في العقود الصارمة.
• القيم صحيحة: المعرّفات والمجاميع والتواريخ بصيغة ISO 8601 والتعدادات ضمن المجموعة المسموحة.
• الأخطاء متسقة: الشكل نفسه في كل نقطة نهاية، ورمز آلي ثابت، ولا تتبّع مكدس أو SQL في الرسالة.
• زمن الاستجابة ضمن الميزانية المتفق عليها.

جرّبها: مدقّق استجابات API جرّبها: مدقّق مخططات API

الأعطال الأكثر شيوعاً

• 200 OK مع خطأ داخل الجسم — لا يستطيع العملاء التمييز بين النجاح والفشل دون تحليل النص.
• 500 للمدخلات السيئة بدلاً من 400/422 — طبقة التحقق مفقودة أو تنهار.
• أشكال خطأ مختلفة في نقاط نهاية مختلفة — كل مستهلك يحتاج معالجة مخصصة.
• تغييرات صامتة في العقد — حقل أُعيدت تسميته أو نوع تغيّر دون رفع الإصدار.
• فحوصات تفويض مفقودة — الرمز صالح لكنه يخص مستخدماً لا يجب أن يرى المورد.
• تقسيم صفحات غير متسق — أحجام الصفحات والإزاحات والمجاميع تختلف بين نقاط النهاية.
• أخطاء المناطق الزمنية — طوابع زمنية بلا إزاحة، أو تواريخ تنزاح يوماً كاملاً.

جرّبها: محاكي رموز حالة API جرّبها: مقارنة عقود الاستجابات

اختبار Webhooks والاستدعاءات العكسية

تعكس Webhooks الاتجاه: الواجهة هي التي تستدعيك. ولاختبارها تحتاج إلى رابط يقبل الاستدعاء ويعرض لك بالضبط ما وصل — الترويسات والتوقيع والجسم والتوقيت — لتتحقق من الحمولة مقابل التوثيق وتتأكد من التوقيع بالسر المشترك قبل كتابة سطر واحد من كود المعالجة.

جرّبها: مختبِر Webhook جرّبها: محلّل توقيعات Webhook

أدوات اختبار API: تطبيقات سطح المكتب مقابل أدوات المتصفح

تطبيقات Postman وInsomnia وBruno ممتازة للمجموعات الكبيرة طويلة العمر. أما للعمل اليومي — فحص نقطة نهاية، أو إعادة إنتاج خطأ، أو التحقق من استجابة، أو التقاط Webhook — فأداة المتصفح أسرع لأنه لا يوجد ما يُثبَّت أو يُسجَّل الدخول إليه. تغطي أدوات API في متقن تلك الحلقة اليومية: إنشاء الطلبات وإرسالها، والتحقق من الاستجابات وفق قواعد أو مخطط، ومحاكاة رموز الحالة، والتقاط Webhooks، وتوليد حالات اختبار مباشرة من ملف OpenAPI.

جرّبها: مولّد حالات اختبار من OpenAPI جرّبها: محلّل زمن الاستجابة

الأسئلة الشائعة