تخيل أنك تطلب قهوة من مقهى. أنت تخبر النادل بطلبك (مثلاً: 'قهوة بالحليب، سكر قليل'). النادل (وهو هنا يمثل الأداة التي تستخدمها) يعرف بالضبط كيف يوصل طلبك إلى صانع القهوة (وهو هنا يمثل API). صانع القهوة لديه قواعد محددة لفهم الطلبات (مثلاً: ما هي «قهوة بالحليب»، وكم هو «سكر قليل»). هذه القواعد المتفق عليها بين النادل وصانع القهوة هي ما نسميه «عقد» API.
الآن، ماذا يحدث لو قام صانع القهوة بتغيير طريقة تحضير «قهوة بالحليب»؟ ربما غير اسمها إلى «لاتيه عادي»، أو أصبح يطلب منك تحديد نوع الحليب في كل مرة. إذا لم يقم النادل بتحديث قائمة الطلبات التي يفهمها أو طريقة صياغة الطلبات، فإن طلبك القديم لن يتم فهمه. النادل سيفشل في توصيل طلبك بشكل صحيح، أو حتى قد يطلب منك مجدداً توضيح ما تريده.
هذا هو بالضبط ما يحدث مع أدوات الذكاء الاصطناعي التي تعتمد على APIs. الأداة (النادل) تتوقع أن تتحدث إلى الخادم (صانع القهوة) بطريقة معينة، باستخدام أسماء حقول محددة، وبصيغ معينة للبيانات. إذا قام مطورو API بتغيير أي جزء من هذا «العقد» – مثل إعادة تسمية حقل مطلوب، أو إضافة متطلب جديد، أو تغيير شكل الرد – فإن الأداة القديمة لن تفهم التغيير و«تنكسر».
مثلاً، إذا كان API يتوقع منك إرسال «id» للعميل، ثم أصبح يتوقع «customer_id»، فإن الأداة القديمة التي ترسل «id» ستفشل. أو إذا كانت أداة الذكاء الاصطناعي تعرض حالات مثل «مفتوح» و«مغلق»، ثم أضاف API حالات جديدة مثل «معلق» أو «تم الحل»، فإن الأداة قد لا تتمكن من معالجة هذه الحالات الجديدة بشكل صحيح.
لذلك، عندما تتغير APIs، يجب تحديث الأدوات التي تعتمد عليها. هذا يضمن أن «النادل» (الأداة) يعرف دائمًا كيف يتحدث بشكل صحيح إلى «صانع القهوة» (الخادم)، لتستمر خدماتك وأدواتك في العمل بسلاسة دون مفاجآت. الهدف هو تجنب تعطل عملك بسبب تغيير بسيط في الخلفية.