راقب استخدام مفتاحك قبل أن تبلغ الحد
متابعة ترويسات الحصة أولًا بأول تخبرك متى يقترب الحد، قبل وقت طويل من رفض أي طلب فعليًا.
من السهل سوء التعامل مع طلب يعود بنجاح دون نتيجة مفيدة بداخله، لأنه لا يبدو فشلًا على مستوى HTTP، بل ببساطة لا يحمل الإجابة التي كنت تأملها.
البحث بالترميز الجغرافي الأمامي عن شيء غامض جدًا أو خيالي تمامًا يعيد الحالة 200 مع مصفوفة نتائج فارغة، لا رمز خطأ.
GET /v1/forward?q=xyzzy nonexistent place&limit=1{
"status": "ok",
"query": "xyzzy nonexistent place",
"results": []
}الاستعلام عن IP لعنوان في نطاق غير مخصص أو خاص يعيد found: false بدلًا من خطأ، مع أي حقول لا يزال بإمكانه ملؤها.
{
"status": "ok",
"ip": "10.0.0.5",
"version": 4,
"found": false
}تحقق من وجود مصفوفة نتائج فارغة، أو found: false، كفرع مستقل في شيفرتك، منفصل عن مسار النجاح وعن مسار معالجة الأخطاء لاستجابات 4xx و5xx معًا. وقرر عن قصد ما يحدث بعد ذلك: اطلب من المستخدم تحسين ما أدخله، أو انتقل إلى بحث أوسع بحد أعلى للنتائج، أو اعرض رسالة واضحة مثل "لم يُعثر على الموقع" بدلًا من مساحة فارغة أو قيمة افتراضية مضللة.
المكان غير الموجود فعلًا سبب واحد، لكن نص إدخال سيئ التنسيق، أو خطأ إملائي، أو استعلام يخلط لغات أو أنظمة كتابة بشكل غير متوقع، قد يؤدي أيضًا إلى نتيجة فارغة لعنوان موجود فعلًا. وقبل أن تفترض أن الموقع نفسه غير موجود، فكّر فيما إذا كان توحيد صيغة الإدخال أو تجربة نسخة مع ضبط المعلمة countries سيحل المشكلة.
تتبّع عدد المرات التي يصل فيها تكاملك إلى مسار النتيجة الفارغة، بشكل منفصل عن معدل الأخطاء. فارتفاع معدل النتائج الفارغة يشير غالبًا إلى مشكلة في جودة البيانات في مرحلة سابقة، في طريقة جمع العناوين أو تنسيقها، لا إلى خلل في الاستعلام نفسه.
النتيجة الفارغة تكلف طلبًا واحدًا أيضًا، مثل المطابقة الناجحة تمامًا، لأن الاستعلام أُجري في الحالتين. ولا يوجد سعر مخفض منفصل للاستعلام الذي يعود فارغًا.
التعامل مع النتيجة الفارغة كنتيجة مقصودة قائمة بذاتها، لا كفكرة لاحقة مُلحقة بمعالجة الأخطاء، يجعل التكامل أمتن بشكل ملحوظ. تتناول صفحة الأخطاء استجابات الأخطاء الفعلية، بينما النتائج الفارغة موثقة إلى جانب شكل الاستجابة العادي لكل نقطة نهاية، مثل توثيق الترميز الجغرافي الأمامي.