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