راقب استخدام مفتاحك قبل أن تبلغ الحد
متابعة ترويسات الحصة أولًا بأول تخبرك متى يقترب الحد، قبل وقت طويل من رفض أي طلب فعليًا.
بعض واجهات API تعيد معرّف مهمة للدفعة الكبيرة وتتوقع منك أن تستطلع حالتها دوريًا أو تنتظر Webhook أثناء معالجتها في الخلفية. أما هذه الواجهة فلا تعمل بهذه الطريقة. فكل طلب مجمّع، كبيرًا كان أم صغيرًا، يُجاب عنه بشكل متزامن في الاستدعاء نفسه، وهذا يغير طريقة تفكيرك في تشغيل مهمة كبيرة جدًا.
بدلًا من إرسال مصفوفة ضخمة واحدة والانتظار، قسّم المهمة الكبيرة إلى أجزاء ثابتة الحجم، يضم كل منها من بضع مئات إلى بضعة آلاف من العناصر، وأرسلها كسلسلة من طلبات POST مجمّعة عادية. ولأن كل استدعاء يعيد نتائجه فورًا، لا توجد حالة مهمة تستطلعها، بل فقط الجزء التالي الذي ترسله.
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]أقرب شيء إلى الاستطلاع الدوري في هذا الإعداد هو مراجعة ترويسات الحصة الخاصة بك بين الأجزاء بدلًا من مراجعة حالة مهمة. اقرأ X-Quota-Free-Remaining وX-Credits-Remaining بعد اكتمال كل جزء، وأوقف المهمة مؤقتًا، أو أنهها، إذا كنت على وشك تجاوز حصتك اليومية المجانية دون رصيد مسبق الدفع كافٍ للمتابعة.
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50سكربت صغير يمر على الأجزاء، ويرسل كلًا منها، ويراجع الترويسات في الاستجابة، ثم يتابع أو يتوقف مؤقتًا بناءً على ما يراه، هو كل ما تحتاجه مهمة دفعات كبيرة هنا. ولا توجد نقطة نهاية منفصلة لحالة المهمة يجب استدعاؤها، لأن الجزء الذي أرسلته للتو يحتوي أصلًا على كل ما طلبته.
تتبّع رقم آخر جزء عالجته بنجاح حتى الآن، حتى يتمكن التوقف المؤقت بانتظار إعادة تعيين الحصة أو شحن الرصيد من الاستئناف من حيث توقف تمامًا، بدلًا من إعادة معالجة أجزاء سابقة وإنفاق الطلبات مرتين.
التكلفة واحدة في الحالتين، طلب واحد لكل عنصر على امتداد المهمة كلها. فنهج التقسيم يغير فقط طريقة إدارتك للمهمة، لا عدد الطلبات التي تستهلكها إجمالًا.
التعامل مع المهمة الكبيرة كسلسلة من الأجزاء المتزامنة العادية، بدلًا من البحث عن نظام مهام غير متزامن غير موجود هنا، يبقي الأمر كله بسيطًا. ويتناول توثيق حدود معدل الطلبات ترويسات الحصة التي يقوم عليها هذا النمط.