استدعاءات API: تقليل العمل وضبط إعادة المحاولة

الخلاصة

تتجنب الواجهة الفعالة التبادل غير الضروري مع الحفاظ على حداثة البيانات وصحة النتيجة. عدد الاستدعاءات وحجم النقل ومدة الانتظار مقاييس منفصلة.

ممر آمن للخوادم والشبكات دون أشخاص
في هذا المقال

مقارنة المسار نفسه

مثال افتراضي بكيلوبايت عشري: يبدأ المسار بـ 100 استدعاء وحجم 100 kB لكل استجابة، ثم يصبح 20 استدعاء بحجم 50 kB. ينخفض النقل من 10000 إلى 1000 kB، أي بنسبة 90 %. لا يثبت ذلك انخفاض زمن الاستجابة بالنسبة نفسها. يشمل الحساب محتوى الاستجابات فقط، دون الطلبات والترويسات.

مقياس افتراضيالأصليالبديل
الاستدعاءات10020
حجم الاستجابة100 kB50 kB
إجمالي النقل10000 kB1000 kB
مدة المسارتحتاج إلى قياستحتاج إلى قياس

التقليل قبل زيادة التوازي

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

منع تكرار إجراء مكتمل

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

المراجع الأساسية

فحص العمليات التي تقف وراء استجابة API واحدة.

يمكن لاستعلام GraphQL واحد أن يُفعّل العديد من الاستدعاءات اللاحقة. قد يُخفي زمن الاستجابة الظاهر للعميل تكلفة المُحلِّلات والقوائم والعلاقات المُتَجَسَّدة.

  • تتبُّع عملية من العميل إلى الخدمات اللاحقة.
  • مقارنة تكلفة الحقل والحجم المُستخدَم فعليًا.
  • القوائم المُرتبطة والاستعلامات المُكرَّرة قبل التخزين المؤقت.

المصدر الأساسي: OWASP — GraphQL Cheat Sheet. المنهج المرتبط: اقرأ الدليل العملي.

Retry-After: الانتظار والميزانية وقرار الإعادة

الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.

Reducing API calls includes controlling repetition

An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.

  • Trace SDK and proxy retries under one logical identifier.
  • Avoid shortening server instructions merely to fit a budget.
  • Verify an uncertain write’s state before creating a new intention.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS