أخطاء API الشائعة وكيفية إصلاحها

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

لن يرغب أي من أصحاب المصلحة في حدوث ذلك. لهذا السبب يظل الاختبار في حالة تأهب للإصدارات الناجحة ويضمن استجابة إيجابية للميزات التي تضيفها. يستلزم ذلك سيناريوهات حالة الاستخدام الأكثر شيوعًا للتحقق من أن التدفقات تعمل على النحو المتوقع قبل أن تتاح الفرصة لأي من عملائك الحقيقيين للتحقق من ذلك.

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

على سبيل المثال ، يريد المستخدم إضافة بعض العناصر إلى عربة التسوق ، ويضغط على الزر المقابل الذي يقوم بتشغيل طلب واجهة برمجة التطبيقات ، ويتلقى الاستجابة ، ويتم تحديث سلة التسوق. إذا فشل هذا الطلب ، فستتعطل ميزة "إضافة إلى سلة التسوق".

هذه هي الطريقة التي يمكن أن تؤثر بها مشكلات واجهة برمجة التطبيقات على الأعمال ، مضيفًا عاملًا أكثر أهمية لماذا يجب على الجميع اختبارها بشكل صحيح. لدمج هذا الاختبار ، يجب على المرء أن يبدأ بأدوات اختبار API الخاصة بالتشغيل الآلي للتأكد من عدم حدوث أخطاء.

يمكن أن تكون هناك أخطاء مختلفة في واجهة برمجة التطبيقات ، وسنخبرك هنا بالمزيد عن أكثر 5 أخطاء شيوعًا: 

أسلوب HTTP غير صحيح

أبسط خطأ API ، لكنه منتشر على نطاق واسع هو طريقة HTTP غير الصحيحة. في كثير من الأحيان ، تحدث المشكلة بسبب الثغرات في الوثائق. قد يكون أحد الأمثلة هو إرسال طلب GET يحدد خيار البيانات ، لكن تخطي ذكر معلمة -X GET. نتيجة لذلك ، يتم تحويله تلقائيًا إلى طلب POST. أيضًا ، قد تحدث مشكلات طرق HTTP عند تبديل أدوات واجهة برمجة التطبيقات لأن بعضها قد يستخدم طريقة واحدة لإنشاء بيئات اختبار وتعديلها ، بينما يستخدم البعض الآخر طرقًا منفصلة لهذه الإجراءات. هذا هو السبب في أنه من المهم التحقق بعناية من هذه الفروق الدقيقة ، وكذلك اعتماد نهج ثابت لكتابة الوثائق الخاصة بك. 

استخدام بروتوكول خاطئ

خطأ شائع آخر هو التناقضات بين بروتوكولات https: // و http: //. قد تدعم بعض واجهات برمجة التطبيقات واحدًا فقط من البروتوكولات ، دعنا نقول http ، لذا فإن تحديد https: // في هذه الحالة سيؤدي إلى معالجة الطلب بشكل غير صحيح. حتى إذا كان كلاهما مدعومًا ، فقد تكون هناك مشكلات في إعادة التوجيه إلى https: // عند تحديد http: //. قد تحدث الحالة أيضًا عندما يقوم موفرو واجهات برمجة التطبيقات (APIs) التابعة لجهات خارجية التي تخطط لاستخدامها بإجراء بعض التغييرات وفشلوا في إرسال إشعار بذلك. لذلك من الأفضل إعادة التحقق من هذه الجوانب من وقت لآخر. لإنشاء واجهة برمجة التطبيقات الخاصة بك ، من الأفضل استخدام بروتوكول https: //. لجعل ذلك ممكنًا ، يلزم تثبيت شهادة SSLللمضيف. منذ بعض الوقت ، كانت شهادات SSL باهظة الثمن بعض الشيء ، لذا فقد تكون هناك شكوك بشأنها ، ولكن مع مزودي الخدمة المجانية مثل Letsencrypt أو Cloudflare ، أصبح الأمر أسهل من أي وقت مضى.

عدم وجود رسائل خطأ ذات مغزى

إذا واجهت " خطأ غير متوقع في واجهة برمجة التطبيقات"، كما تعلمون كم قد يكون هذا مزعجًا. عادة ، من المفترض أن تسهل رسائل الخطأ استكشاف الأخطاء وإصلاحها للمطورين مع الإشارة إلى السبب الدقيق للخطأ أو على الأقل مكان البحث عنه. لسوء الحظ ، يمكن أن تؤدي مثل هذه الأخطاء غير المفيدة إلى ساعات من الأوقات الضائعة ، وزيادة الوقت المطلوب لحل الخطأ ، وبالتالي تسبب ارتفاعًا أكبر في التعليقات السلبية التي تتلقاها ، ولهذا السبب من الأفضل قضاء المزيد من الوقت قليلاً في وصف الإمكانات الأخطاء وجعل الرسائل مفيدة لأولئك الذين سيحتاجون إلى استكشافها وإصلاحها. على الرغم من وجود العشرات من رموز خطأ HTTP ، فليس مطلوبًا استخدامها جميعًا ، ولكن احتفظ برموز الخطأ القياسية (200 و 400 و 500) وفكر في تضمين التلميحات في الرسائل حتى في الحالات التي لا يعمل فيها شيء ما ،

مشكلة الإذن

قد يبدو أن كل شيء هنا واضح لأن التفويض الخاطئ عادة ما يفترض مسبقًا أن اسم المستخدم أو كلمة المرور غير صحيحة ، ولكن في الواقع ، حتى الخلط بين "التفويض" و "المصادقة" في العناوين يتسبب في حدوث الخطأ. إنه صالح بشكل خاص في استخدام بروتوكول OAuth 2. كما أن التركيب اللغوي مهم أيضًا ، لأن بعض الأشياء البسيطة ولكنها أقل وضوحًا يمكن أن تسبب الارتباك. في معظم الحالات ، تكون هذه هي رمز الحامل ، والمسافة في البادئة "الأساسية" ، والمفقودة لإضافة هذه البادئة تمامًا ، وفقدان النقطتين في زوج "اسم المستخدم: كلمة المرور". حتى عند استخدام اسم المستخدم بمفرده في بعض واجهات برمجة التطبيقات التي لا تتطلب كلمة المرور ، فستظل بحاجة إلى استخدام هذه النقطتين.

فشل في تحديد نوع المحتوى وقبول الرؤوس

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

يتم إحتوائه

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