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