تُعد واجهة برمجة التطبيقات (API) بمثابة “عقد” يستخدمه العميل (client) لطلب تنفيذ مهمة ما من النظام. وفي سياق المقابلات التقنية، يجب أن يضمن هذا العقد سهولة تنفيذ إجراءات المستخدم الرئيسية وقابليتها للتنبؤ، مثل إنشاء ملاحظة، أو قراءتها، أو تعديلها، أو حذفها، أو مشاركتها مع الآخرين. كما ينبغي أن يتجنب العقد أي غموض قد يؤدي إلى مخاطر برمجية؛ كوجود نقطتي نهاية (endpoints) مختلفتين تقومان -بشكل أو بآخر- بتحديث الملاحظة نفسها، ولكنهما تتصرفان بطرق مختلفة عند تلقي المدخلات ذاتها. ولتوضيح هذا المفهوم عملياً، دعنا نطبقه على أبسط نموذج ممكن لتطبيق ملاحظات، حيث يتواصل تطبيق (سواء على الهاتف المحمول أو الويب) مع خدمة خلفية (backend service) واحدة تتولى تخزين الملاحظات في قاعدة بيانات.
في هذا التصميم الأساسي، يرسل العميل (Client) طلب HTTP إلى خدمة واجهة برمجة التطبيقات (API)، حيث تقوم الخدمة بالتحقق من صحة الطلب وتطبيق قواعد العقد البرمجي، بينما تتولى قاعدة البيانات تخزين سجلات الملاحظات لضمان أن عمليات القراءة المستقبلية ستُظهر الحالة ذاتها. تكمن النقطة الجوهرية هنا في مبدأ “التحكم والمسؤولية” (Agency)؛ إذ يختار العميل الإجراء المطلوب استدعاؤه، وتقرر خدمة API ما هو مسموح به وما سيتم كتابته، وتعمل قاعدة البيانات على حفظ النتيجة بشكل دائم لتكون متاحة للطلب التالي. هذا هو النمط الذي سنركز عليه لاحقاً عندما تصبح قدرات الخادم الواحد غير كافية.
تتميز واجهة برمجة التطبيقات (API) الأبسط والأكثر فاعلية بتسمية الموارد بوضوح وربط كل نقطة نهاية (endpoint) بإجراء واحد للمستخدم وبنية محددة للكائن المخزن. تُعرَّف الملاحظة (Note) ككائن يضم مُعرِّفاً (id)، ومُعرِّف المستخدم المالك (ownerUserId)، والعنوان (title)، والمحتوى (body)، والطوابع الزمنية؛ وتضيف خاصية المشاركة قاعدةً تتيح لمستخدم آخر قراءة الملاحظة أو تعديلها بناءً على صلاحيات محددة. وبهذا، يمكن لمجموعة محدودة من نقاط النهاية تغطية مسار العمليات الأساسي دون الحاجة لابتكار أفعال إضافية أو تحميل المصطلحات دلالات مركبة ومعقدة. إن الربط المباشر بين كل نقطة نهاية ومسار للقراءة أو الكتابة هو ما يحافظ على وضوح العقد البرمجي وسهولة فهمه حتى في ظل ظروف العمل المكثفة. لنقم الآن بمطابقة نقاط النهاية هذه مع الخدمة الأساسية وعمليات القراءة والكتابة في قاعدة البيانات.