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