معالجة الأخطاء واختبار واجهات REST البرمجية

Name: معالجة الأخطاء واختبار واجهات REST البرمجية
Author: Josh Guardino

تعرف على كيفية التعامل مع أخطاء REST API وإنشاء الاختبارات الآلية وتشغيلها

شاهد الدرس الأول مجانًا — احصل على وصول كامل إلى جميع الدروس الـ3.

دورة تدريبية: عند الطلب

مرحبًا، اسمي جوش جاردينو، وسأوضح لك في هذه الدروس كيفية التعامل مع الأخطاء واختبار REST APIs. تذكر أن أكواد حالة استجابة HTTP مقسمة في عدة مجموعات. تعتبر أكواد الحالة في النطاق 400 و 500 أخطاء. ومع ذلك، فإن الاختلاف الهام هو أن أكواد الحالة التي تبدأ برقم أربعة هي أخطاء العميل وأكواد الحالة التي تبدأ بخمسة هي أخطاء في الخادم. قد تكون أخطاء العميل أخطاء تتعلق بالطلب نفسه. ربما احتوى الطلب على JSON منسق بشكل غير صحيح، الوصول إلى المسار المطلوب ممنوع، تعذر العثور على المورد المطلوب والمزيد. عندما تحدث أخطاء العميل، من المهم أن يقوم الخادم بالرد مع كود حالة السلسلة 400 الصحيح. ومع ذلك، الحفاظ على التفاصيل الكاملة حول خطأ العميل ليست مطلوبة عادة على جانب الخادم. يجب أن يكون العميل قادرًا على معالجة المشكلة وإرسال طلب جديد. مزيد من القلق من جانب الخادم هي أكواد خطأ الخادم، وهذه هي التي تبدأ برقم خمسة. على الرغم من وجود العديد من أكواد الاستجابة لأخطاء الخادم، إلى حد بعيد، أهمها وأكثرها صلة هو 500. 500 يشير إلى خطأ داخلي في الخادم لحالة غير متوقعة من جانب الخادم، مما يعني حدوث خطأ. الغرض من كود الحالة 500 ليكون استجابة شاملة. ومع ذلك، فهو عادةً النوع الوحيد من كود الخطأ من جانب الخادم الذي يحتاج كود جانب الخادم REST API إلى التعامل معه. قد تكون مصادفة أكواد خطأ أخرى من جانب الخادم من قبل العميل، مثل 503 الذي يشير أن الخادم غير جاهز. ولكن يتم إرسال هذه الأنواع من الردود عادةً بواسطة بوابة API وليس عن طريق التطبيق نفسه. لنلقي نظرة في قسم API للمركبات في Postman. هنا نقطة نهاية v1 / driver GET endpoint وعندما أنقر فوق إرسال، يتم إرجاع كود الحالة 200 وقائمة بجميع السائقين من قاعدة البيانات. الآن دعنا نرى كيف يبدو هذا في كود المصدر. هنا هو معالج طريقة GET. ينفذ استعلام تحديد في قاعدة البيانات وإرجاع كافة البيانات. هذا يعمل بشكل جيد في حالة عدم وجود أخطاء. ومع ذلك، دعنا نفرض حدوث خطأ. في السطر 12، سأقوم بإدخال كود غير صالح. دعنا نعيد تشغيل الخادم ونعود إلى Postman. سأضغط على إرسال وكما ترى، لم أتلق كود الحالة أو أي نوع من الردود. يُظهر Postman خطأ ECONNRESET. هذا يعني أن الخادم لم يستجب بأي شيء يمكن لـ Postman معالجته. دعنا نعود إلى حيث يتم تشغيل الخادم. اكتشف الخادم المحلي خطأ xyz بدقة وعرض التفاصيل الكاملة لنافذة وحدة التحكم. تسمى هذه التفاصيل تتبع المكدس وهي مهمة جدًا لأغراض تصحيح الأخطاء. يخبرني السطر الأول في إخراج الخطأ أن هذا كان خطأ مرجعي لأن الخادم لم يفهم ما هو xyz، لذا يتم التقاط الخطأ بشكل صحيح لكن العميل ليس لديه فكرة عما حدث. قد يكون الخادم معطلاً، قد تكون هناك مشكلة في الشبكة من جانب العميل، قد يكون هناك خطأ من جانب الخادم لكن ليس لدى العميل طريقة لمعرفة ما حدث وذلك لأن هذا الكود لا يؤدي أي نوع من معالجة الخطأ. عندما يحدث الخطأ، اكتشف الخادم حدوث خطأ ما ولكن لم يتم إرسال أي رد بسبب طريقة GET، النوع الوحيد من الردود المرسلة هو 200. الآن، دعنا نضيف بعض معالجة الأخطاء إلى تطبيق Node.js Express مع عبارات المحاولة والتقاط Try & Catch. الآن يتم معالجة الخطأ وسيتم اكتشاف جميع الأخطاء في السطر 16. في السطر 17 ، أرسل حالة 500 إلى العميل. دعنا نعود إلى ساعي البريد ونجرب ذلك. الآن، عندما أرسل الطلب، أتلقى ردًا ولديه كود الحالة 500 يشير إلى خطأ داخلي في الخادم. العميل لا يعرف بالضبط ما حدث على جانب الخادم، ولكن به معلومات أكثر بكثير من الطلب السابق. من الممكن بالتأكيد إرسال التفاصيل الكاملة من الخطأ إلى العميل، جنبًا إلى جنب مع كود حالة خطأ الخادم الداخلي 500 لكن هذا بالتأكيد إشكالية. الأهم من ذلك، أن هذا يكشف التفاصيل الداخلية حول API وهذا يمثل مشكلة أمنية خطيرة محتملة ولكن أيضًا، هذه المعلومات ليست مفيدة للعميل، لذلك لا يوجد سبب لإرساله لكن هذا لا يعني أن الخادم يجب أن يعرض رسالة استجابة عامة للخادم. دعنا نعود إلى الكود وإضافة رسالة خطأ ودية. الآن، عندما نرسل هذا الطلب، ما زلنا نتلقى 500 ولكن برسالة خطأ مخصصة. سبب آخر لاستخدام رسالة كود الحالة 500 المخصصة هو تزويد العميل بالتتبع أو معرف الارتباط أن الموظفين على جانب العميل من API يمكن مشاركته مع موظفي جانب الخادم من أجل إجراء استكشاف الأخطاء وإصلاحها بشكل مفصل. شكرا للمشاهدة. ترقب الدرس التالي حيث سأريك كيفية استخدام الاختبار الآلي لطلبات GET في REST API.

مبتدئ مقدِّم الخدمة : Josh Guardino 3 الدروس · 17m باللغات: العربية, الألمانية, الإنجليزية, الإسبانية, الفرنسية, البرتغالية, Chinese

وصف الدورة

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

للتعامل مع ما هو غير متوقع، من المهم لعملاء وخوادم RESTful التعامل مع هذه الظروف بأمان. في هذه الدروس، ستتعرف على كيفية حدوث الأخطاء على كلا الجانبين وكيف يمكن معالجة مجموعة تفاصيل الخطأ وأكواد الحالة والرسائل بالطريقة المثلى.

أفضل دفاع ضد عدم الاستقرار وعدم التناسق مع البرنامج هو اختباره بشكل متسق ومنتظم. سنوضح لك كيفية استخدام TestProject وهي أداة مجانية قائمة على الويب، لبرمجة اختبارات REST API وأتمتتها لاكتشاف حالات الخطأ وتحديدها وتوفير معلومات مفيدة لتصحيح الأخطاء وضبط الأداء.

ما ستتعلمه

تحديد أكثر أنواع أخطاء REST API شيوعاً ورموز الحالة المقابلة لها
التعرف على كيفية حدوث الأخطاء على جانبَي العميل والخادم في واجهة برمجة التطبيقات
معالجة تفاصيل الأخطاء ورموز الحالة والرسائل بالطريقة المثلى للتعامل مع الحالات غير المتوقعة بسلاسة
تهيئة TestProject وتشغيله لكتابة اختبارات REST API وأتمتتها لطلبات GET
تهيئة TestProject وتشغيله لطلبات POST وPUT وPATCH وغيرها من طلبات الكتابة
استخدام اختبار REST API الآلي للكشف عن حالات الخطأ وتوفير المعلومات اللازمة لتصحيح الأخطاء وضبط الأداء

النقاط الرئيسية

واجهات برمجة التطبيقات هي تطبيقات موزعة تربط عملاء وخوادم بعيدة عبر شبكة، مما يُفضي إلى كثير من المخاطر المحتملة كتعطل الخوادم والشبكات أو فشل العملاء في معالجة الطلبات والاستجابات.
ينبغي لعملاء وخوادم RESTful التعامل مع الحالات غير المتوقعة بسلاسة من خلال الجمع بين تفاصيل الأخطاء ورموز الحالة والرسائل ومعالجتها بالطريقة المثلى.
الاختبار المنتظم والمستمر هو أفضل وسيلة للحماية من عدم استقرار البرمجيات وتناقضها.
TestProject هو أداة مجانية تعمل عبر الويب تُستخدم لكتابة اختبارات REST API وأتمتتها بهدف تحديد حالات الخطأ ودعم تصحيح الأخطاء وضبط الأداء.
يتناول المقرر معالجة طلبات GET وطلبات الكتابة كـ POST وPUT وPATCH.

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

ما الذي يتناوله هذا المقرر؟

يتناول كيفية حدوث الأخطاء على جانبَي العميل والخادم في REST APIs، وكيفية معالجة تفاصيل الأخطاء ورموز الحالة والرسائل بالطريقة المثلى، وكيفية استخدام TestProject لكتابة اختبارات REST API وأتمتتها للكشف عن حالات الخطأ ودعم تصحيح الأخطاء وضبط الأداء.

ما أداة الاختبار المستخدمة في هذا المقرر؟

يستخدم المقرر TestProject، وهي أداة مجانية تعمل عبر الويب، لكتابة اختبارات REST API وأتمتتها.

ما أنواع طلبات واجهة برمجة التطبيقات التي يعلمك المقرر اختبارها؟

يعلمك المقرر تهيئة TestProject وتشغيله لطلبات GET وكذلك لطلبات POST وPUT وPATCH وغيرها من طلبات الكتابة.

ما المهارات التي يساعد هذا المقرر على بنائها؟

يعالج المقرر مهارات تشمل تصميم واجهات برمجة التطبيقات، وإدارة واجهات برمجة التطبيقات، واختبار واجهات برمجة التطبيقات، وتطوير REST API، وعميل REST، وRESTful API.

ما الدروس المتضمنة في هذا المقرر؟

يشتمل المقرر على ثلاثة دروس: معالجة أخطاء REST API والاختبار؛ وأساليب HTTP GET؛ وطلبات POST وPUT وPATCH.