5 أخطاء في REST API كلفتني مستخدمين
قبل ثلاث سنوات، قمت ببناء أول API عام لي. اعتقدت أنني انتهيت منه في عطلة نهاية أسبوع واحدة. انتظرت وصول المستخدمين.
لقد جاؤوا. ثم غادروا.
كان المنتج جيداً. لكن الـ API كان صعب الاستخدام. ارتكبت خمسة أخطاء جسيمة. إليك كيف قمت بإصلاحها.
- استخدام 200 OK للأخطاء كنت أرسل حالة 200 OK حتى عندما تفشل العمليات. كنت أضع رسالة الخطأ داخل جسم الـ JSON. أجبر هذا المطورين على كتابة منطق مخصص لكل استدعاء على حدة.
الإصلاح: استخدم رموز حالة HTTP الصحيحة.
- استخدم 400 للمدخلات غير الصحيحة.
- استخدم 401 لفشل المصادقة.
- استخدم 404 للموارد المفقودة.
- استخدم 429 لتجاوز حدود المعدل.
- نسيان الإصدارات (Versioning) قمت بتغيير حقول البيانات الخاصة بي دون سابق إنذار. أدى تغيير واحد إلى تعطل كل عملية تكامل كنت أملكها.
الإصلاح: ابدأ مساراتك (routes) بـ /v1/. هذا يمنع تعطل العملاء الحاليين عند تحديث الكود الخاص بك. احتفظ بإصدارك الحالي وإصدار واحد سابق.
- عدم وجود تحديد لمعدل الطلبات (Rate Limiting) قام أحد البرامج النصية (scripts) التي تحتوي على أخطاء بالاتصال بنقطة نهاية البحث (search endpoint) الخاصة بي 200 مرة في الثانية. أدى ذلك إلى استهلاك كامل موارد قاعدة البيانات، وتسبب في تعطل النظام للجميع.
الإصلاح: قم بتنفيذ تحديد لمعدل الطلبات. استخدم نهج "token-bucket". أرجع حالة 429 Too Many Requests مع ترويسة (header) Retry-After.
- تنسيقات أخطاء غير متسقة كانت رسائل الخطأ الخاصة بي تبدو مختلفة اعتماداً على مكان حدوث الخطأ. استخدم أحد الأخطاء "msg" بينما استخدم آخر "message". اضطر المطورون لكتابة أدوات تحليل (parsers) متعددة لـ API واحد.
الإصلاح: اختر هيكلاً واحداً للخطأ واستخدمه في كل مكان. يجب أن تحتوي كل رسالة خطأ على نفس المفاتيح (keys).
- إرجاع الكثير من البيانات كانت نقطة النهاية /users الخاصة بي تعيد كل مستخدم في قاعدة البيانات. عندما وصلنا إلى 10,000 مستخدم، تسبب حجم الاستجابة في تعطل تطبيقات الهاتف المحمول.
الإصلاح: استخدم الترقيم المستند إلى المؤشر (cursor-based pagination). هذا يحافظ على صغر حجم الاستجابات واستقرارها، وهو أسرع لمجموعات البيانات الكبيرة من الترقيم المستند إلى الإزاحة (offset-based pagination).
النتائج:
- انخفض وقت التكامل من 3 أيام إلى 4 ساعات.
- انخفضت تذاكر الدعم بنسبة 70%.
- عاد المستخدمون السابقون.
الـ API الخاص بك هو منتجك. الواجهة الأمامية (frontend) الجيدة لا يمكنها إنقاذ API سيء.
ما هو أسوأ خطأ في API رأيته؟ أخبرني في التعليقات.
المصدر: https://dev.to/sirmax/5-rest-api-mistakes-that-cost-me-users-and-how-to-fix-them-57gi