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