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