مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا
المفتاح الذي صدر قبل سنوات، ولم يُبدَّل قط، ولا يزال صالحًا حتى اليوم ليس ميزة مريحة. إنه عبء لم ينظر فيه أحد فعلًا منذ سنوات.
لا أحد يشترك في API وهو يخطط للارتهان له. الارتهان لا يأتي كبند في عقد يمكنك التفاوض على إلغائه. بل يتراكم، وسيلة راحة تلو الأخرى، حتى تصبح تكلفة الانتقال قد نمت بصمت لتتجاوز تكلفة المشكلة التي دفعتك إلى التفكير في الانتقال أصلًا.
يبدأ الأمر صغيرًا. تثبّت حزمة SDK الخاصة بالمزود لأنها توفر بضع ساعات من كتابة طلبات HTTP يدويًا. تخزن بنية كائن الاستجابة مباشرة في قاعدة بياناتك بدلًا من ربطها بمخططك الخاص، لأن ذلك الربط بدا عملًا غير ضروري في حينه. تبني معالجة الأخطاء حول رموز الحالة الخاصة بالمزود بدلًا من نمط عام. كل واحد من هذه الخيارات منطقي بمفرده، في لحظته، تحت ضغط التسليم المعتاد. لا يُتخذ أي منها مع التفكير في الارتهان. وكلها تزيده.
بعد سنوات، يرفع المزود أسعاره، أو يتعرض لانقطاع خلال فترة مزدحمة، أو ببساطة يتوقف عن كونه الخيار الأفضل لميزة تحتاجها الآن. كان ينبغي أن يكون الانتقال مسألة اختيار مورّد جديد وتحديث قيمة إعداد. لكنه بدلًا من ذلك يصبح مشروعًا: إعادة كتابة منطق التحليل المتناثر في أرجاء الشيفرة، وإعادة بناء معالجة الأخطاء، وإعادة تكييف كل الأدوات الداخلية التي نشأت حول البنية القديمة. تكلفة الانتقال لم تُحتسب يومًا في فاتورة. لقد دُفعت مقدمًا، في قرارات تكامل صغيرة لم يصنفها أحد كقرارات محفوفة بالمخاطر في حينها.
بنينا المضيفات المتوافقة تحديدًا لمواجهة هذا النمط. إذا كان تكاملك يتحدث بالفعل بنية الطلبات والاستجابات الخاصة بمزود آخر، فإن توجيهه إلى أحد مضيفاتنا المتوافقة البالغ عددها 17 لا يتطلب أن تكون قد خططت لقابلية النقل مسبقًا. تحصل على خيار المغادرة دون أن تكون قد امتلكت بُعد النظر للبناء من أجل المغادرة. وهذا فرق معتبر عن معظم النصائح المضادة للارتهان، التي تميل إلى القول «ابنِ على طبقة تجريد منذ اليوم الأول»، وهي نصيحة جيدة لا يتبعها أحد تقريبًا تحت ضغط المواعيد النهائية.
المصادقة مثال أصغر على المبدأ نفسه. يدفعك بعض المزودين نحو طريقة مصادقة واحدة محددة، فيربطون تكاملك بنمط عميل معين. نحن نقبل المفتاح في ترويسة X-API-Key، أو ترويسة Authorization Bearer، أو عبر HTTP Basic، أو في معامل استعلام، على كل مضيف، ودون أي تكلفة إضافية لأي منها. أيًّا كان النمط الذي تستخدمه شيفرتك الحالية مع واجهات API أخرى، فالأرجح أن واجهتنا تناسبه، فلا تضطر إلى إعادة كتابة طبقة المصادقة لديك لمجرد تجربتنا.
السبب الصادق لاستمرار الارتهان في هذا المجال هو أنه ينجح تجاريًا. العميل الذي كان سيغادر بسبب السعر وحده غالبًا ما يبقى لأن المغادرة تعني إعادة كتابة. نرى أن هذه مقايضة سيئة لبناء عمل تجاري عليها، لأنها تكسب العملاء غير الراضين أصلًا بدلًا من الراضين حقًا. إذا بقيت المغادرة رخيصة، فإن العملاء الذين يبقون يبقون لأن المنتج لا يزال يستحق، لا لأن باب الخروج سُدّ بصمت في مكان ما خلال السنة الثانية.