البرنامج التعليمي القادم على الويب

انضم إلينا في ندوة مجانية عبر الإنترنت حول المعالجة الآلية لملفات EDI الخاصة بالرعاية الصحية باستخدام Astera

27 يونيو 2024 - الساعة 11 صباحًا بتوقيت المحيط الهادئ / 1 ظهرًا بالتوقيت المركزي / 2 ظهرًا بالتوقيت الشرقي

مدونات

الرئيسية / مدونات / 6 أخطاء واجهة برمجة التطبيقات (API) المتكررة وكيفية منع حدوثها

جدول المحتويات
الآلي, لا كود مكدس البيانات

تعلم كيف Astera يمكن لـ Data Stack تبسيط وتبسيط إدارة بيانات مؤسستك.

6 أخطاء API التي تحدث بشكل متكرر وكيفية منع حدوثها

24 يناير، 2024

تعد واجهات برمجة التطبيقات جزءًا مهمًا بشكل متزايد من اقتصاد القرن الحادي والعشرين وحياتنا اليومية. تم بناء شركات ضخمة مثل Stripe و Amazon على منصات مطورين ممتازة. حتى الأدوات "التناظرية" مثل أنظمة هاتف المكتب أصبحت معرضة لواجهات برمجة التطبيقات. تتكامل منتجات VoIP المتقدمة بشكل متزايد أنظمة الهاتف للشركات الصغيرة باستخدام برنامج مثل Google Workspace. هذا يفتح تجارب جديدة قوية للموظفين والعملاء على حد سواء. لكن واجهات برمجة التطبيقات ليست فوق الأخطاء. سواء كنت مطور مشروع هاوٍ أو مليون دولار منتج قائم على SaaS المستخدم، وسوف تجد أن مواطن الخلل أمر لا مفر منه.

ما هو خطأ/فشل واجهة برمجة التطبيقات؟

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

6 أخطاء شائعة في واجهة برمجة التطبيقات

بعض أخطاء واجهة برمجة التطبيقات الشائعة هي:

  • أخطاء HTTP/HTTPS.
  • أخطاء واجهة برمجة التطبيقات غير مفيدة.
  • خلطات الطريقة.
  • رؤوس نوع المحتوى/القبول مفقودة.
  • أخطاء التفويض
  • أخطاء في تنسيق البيانات.

1. أخطاء HTTP / HTTPS

يحدث أحد أكثر أخطاء واجهة برمجة التطبيقات شيوعًا عند وجود التباس بين بروتوكولات http: // و https: // في عناوين URL.

بالنسبة للمطورين ، تكمن المشكلة في أن بعض واجهات برمجة التطبيقات تدعم بروتوكول HTTP فقط بينما يتوافق البعض الآخر مع HTTPS. يدعم البعض معايير مختلفة عند نقاط نهاية مختلفة في نفس المنتج الذي يركز على العميل.

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

إذا كنت من مزود API، يمكنك منع هذا الخطأ من خلال وضع إستراتيجيات HTTPS محددة. على سبيل المثال ، يمكن أن تجعل واجهة برمجة التطبيقات API الخاصة بك تعيد توجيه طلبات HTTP تلقائيًا إلى طلبات HTTPS فور ورودها.

API- يخطئ

2. رسائل خطأ API غير مفيدة

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

يوفر HTTP أكثر من 70 رمز حالة http ، ولكن على الأقل ، تحتاج فقط إلى تنفيذ أكثر الرموز شيوعًا التي اعتاد المطورون التعامل معها. ومن الأمثلة على ذلك:

200 OK

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

400 طلب غير صحيح

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

401 غير مصرح به

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

403 المحرمة

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

404 لم يتم العثور على

طلب المستخدم صالح ولكن نقطة النهاية أو المورد الذي يطلبونه غير موجود. قد يكون هذا بسبب حذف الملف منذ ذلك الحين ، ولكن تأكد من أن هذا ليس بسبب خطأ HTTP / HTTPS.

429 عدد الطلبات أكبر من اللازم

يحدث هذا عندما يحاول نفس المستخدم استدعاء API عدة مرات في تتابع سريع. بعد عدد من هجمات DDoS رفيعة المستوى على مدار العقد الماضي ، تراقب خدمات الويب عن كثب من يقوم بالوصول إلى خادمهم وعدد المرات.

يشبه تحديد المعدل هذا ما تجده في أي مجال أو مواقع كبيرة أخرى. يتعامل موفرو استضافة الويب مثل Cloudflare مع حماية DDoS للنطاقات المستضافة على خوادمهم. بالنسبة لواجهات برمجة التطبيقات ، يجب أن تكون وسائل الحماية مضمنة.

أخطاء 5xx API

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

يمكن لموفري واجهة برمجة التطبيقات تجنب رسائل الخطأ السيئة بقليل من التخصيص ومعالجة الأخطاء. تجاوز رمز الخطأ واستخدم رسائل واضحة وموجزة ترتبط بالوثائق.

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

ألق نظرة على رسالة الخطأ هذه من Twilio ، التي تسمح API الخاصة بها للمطورين بإجراء مكالمة VoIP.

"`

{

"الكود": 21211 ،

"message": "رقم" إلى "5551234567 ليس رقم هاتف صالحًا." ،

“more_info”: “https://www.twilio.com/docs/errors/21211” ،

"الحالة": 400

}

"`

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

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

API- أخطاء

3. طرق الخلط

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

سبب آخر لأخطاء الأسلوب هو التوثيق غير الواضح. يمكن أن يحدث هذا عندما لا يشرح قسم من وثائقك الطرق المطلوبة أو يستخدم الفعل الخطأ تمامًا. (احترس من استخدام كلمة "get" و GET بالتبادل. تأكد من أن تنسيق مستنداتك واضح واحفظ لنفسك بريدًا إلكترونيًا لدعم العملاء.)

4. رؤوس نوع المحتوى / قبول مفقودة

تحتوي معظم مكالمات API على جزأين على الأقل من بيانات الرأس: نوع المحتوى وقبول. تساعد هذه الرؤوس طرفين - مثل واجهتي API - في التفاوض بشأن نوع البيانات التي يتم إرسالها وأي الأنواع سيتم قبولها في المقابل. مثل أي مفاوضات ، يمكن أن تنهار.

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

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

يجب تحديد هذه المعلومات في الوثائق حيث لا يمثل القيام بذلك مخاطرة أمنية ، ولكن بعض أدوات المطورين يمكن أن تؤدي إلى تعثر المستخدمين. ضع في اعتبارك curl ، والذي يتضمن تلقائيًا عنوان Accept الافتراضي في الطلبات. يمكن لموفري واجهة برمجة التطبيقات توقع هذه المراوغات في الأدوات أو تعديل الطلب أو إرسال رسالة خطأ محددة.

5. أخطاء التفويض

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

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

تأكد من تنسيق طلبات واجهة برمجة تطبيقات OAuth 2 على هذا النحو ، باستخدام علامة "Bearer" قبل المفتاح الخاص:

"`

التفويض: الحامل {your_api_key_here}

"`

يجب تنسيق أزواج اسم المستخدم وكلمة المرور مثل "اسم المستخدم: كلمة المرور". ولكن حتى إذا كان طلب واجهة برمجة التطبيقات لا يتطلب كلمة مرور ، فقد يضطر المستخدمون إلى إلحاق نقطتين في النهاية. يمكن لموفري واجهة برمجة التطبيقات إلحاق النقطتين بأنفسهم ، أو توضيح ما هو التنسيق بالضبط في الوثائق.

API- أخطاء

6. أخطاء تنسيق البيانات

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

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

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

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

وأوضح منع الأخطاء

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

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

ربما يعجبك أيضا
كيفية تحميل البيانات من AWS S3 إلى Snowflake
أفضل أدوات Azure ETL لعام 2024
ETL باستخدام بايثون: استكشاف الإيجابيات مقابل السلبيات
مع مراعاة Astera لتلبية احتياجات إدارة البيانات الخاصة بك؟

أنشئ اتصالاً خاليًا من التعليمات البرمجية مع تطبيقات مؤسستك وقواعد البيانات والتطبيقات السحابية لدمج جميع بياناتك.

دعونا نتواصل الآن!
يتيح الاتصال