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