اختبار واجهة برمجة التطبيقات

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

يزيل API Tester هذه الخطوة. فهو يرسل الطلب من داخل الصفحة التي تشاهدها، مثل الصفحة نفسها، لذا فإن كل ما قمت بتسجيل الدخول به هو ما تم تسجيل الدخول به. يعمل GET مقابل نقطة النهاية الإدارية الخاصة بك على الفور لأن ملف تعريف الارتباط ينتقل معها. لا يوجد شيء لتكوينه ولا شيء يمكن مزامنته.

تمنحك علامة التبويب REST طريقة، وعنوان URL يمكن أن يكون مطلقًا أو نسبيًا، ورؤوسًا مكتوبة واحدة في كل سطر، ونصًا. تعود الاستجابة بحالتها، والمدة التي استغرقتها، وحجمها، وJSON المطبوع بشكل جميل، ورؤوس الاستجابة الكاملة. تأخذ علامة التبويب GraphQL نقطة نهاية واستعلامًا ومتغيرات، وتنشئ الطلب لك، وتخبرك عندما تحتوي الاستجابة على أخطاء GraphQL على الرغم من أن حالة HTTP كانت 200. تفتح علامة التبويب WebSocket اتصالاً حقيقيًا، وترسل الإطارات التي تكتبها، وتسجل كل شيء في كلا الاتجاهين باستخدام الطوابع الزمنية.

عندما تقوم سياسة أمان المحتوى الخاصة بالصفحة أو قاعدة CORS بحظر المكالمة، يقوم أحد المحولين بإعادة إرسال الطلب المطابق من الامتداد بدلاً من ذلك، والذي لا يخضع لأي منهما. ويمنحك ذلك طريقة سريعة للتمييز بين مشكلة الخادم ومشكلة سياسة المتصفح - نفس الطلب، وسياقان، وإجابتان. يتم الاحتفاظ بطلباتك الـ 25 الأخيرة، وبالتالي فإن العودة إلى شيء جربته بالأمس هو نقرة واحدة.