أصبحت التطبيقات الحديثة تأتي في عدة أشكال وتدعم عدة منصات تشغيل وتُركّب على أنواع أجهزة لا عدّ لها. أصبحت هذه التطبيقات تفرض على مبرمجيها دعم عملاء (Clients) متعددين ومتنوعين مثل الهواتف الذكية والحواسيب اللوحية بالإضافة إلى صفحات الويب التقليدية.ليستطيع المطور توفير الكثير من الجهد والوقت سوآءاً أثناء التطوير أو الصيانة فإنه يتحتم عليه جمع منطق عمل البرنامج في مكان واحد ومشاركة هذ المنطق مع نسخ العملاء والتي تعمل على المنصات المختلفة. أفضل الطرق الحديثة والتي يُستحسن أن يتبعها المطور أن يقوم ببناء واجهة برمجية لفكرته حتى تزود عملاء (Clients) برنامجه المختلفين بهذا المنطق المشترك وتجعل إدارة هذا المنطق أسهل وصيانته أقل عناء.
قبل أن نتحدث أكثر، يجب توضيح ما المقصود بواجهة التطبيق البرمجية المبنية على الويب.
بدأت الحاجة لواجهات التطبيق البرمجية بشكل عام عندما أصبح من الضروري فتح وظائف برنامج للاستخدام من قبل برنامج آخر ولكن كان وجود البرنامجين على نفس الخادم أو الجهاز ضروريا. مع تقدم تقنية الشبكات، أصبح من الممكن أيضا أن يتحدث البرنامجان عن طريقة الشبكة من بُعد ونشأ بسبب ذلك مجموعات جديدة من هياكل النظم المرتبطة (Network Systems Architectures) لواجهات التطبيق البرمجية تعتمد على وجود الشبكات مثل كوربا (CORBA) في عالم الجافا وDCOM في عالم مايكروسوفت.
بعد انتشار الإنترنت والشبكة العنكبوتية (Web) ظهرت تقنيات تعتمد على الترابط الفضفاض (Loose Coupling) مثل الـ (SOAP) وتعتبر أول من بدأت تقنيات واجهة التطبيقات البرمجية إلا أنه كان لها الكثير من التعقيدات. بدأت بعد ذلك ظهور هيكل النظم المرتبطة المسمى بـ رست (REST) أو (Representational State Transfer) أي هيكل نقل الحالة التمثيلية والذي يعتبر الهيكل القياسي هذ الأيام وسنتحدث عن هذا الهيكل بشكل أكثر في هذه المقالة.
قيود تطوير الواجهة التطبيقية
عند بناءك لواجهة تطبيق برمجية فإنك في العادة ستتأثر بقيود عدة تفرضها عليك تطبيقات العميل (Client Apps). يمكنني إجمال هذه القيود في التالي:
متطلبات وظيفية مختلفة عن بعضها البعض بحسب تطبيق العميل. فمثلاً عند تطوير برنامج لإدارة أعمال منشئة فإن نسخة الويب عادة ما تكون مكتملة الوظائف وتقدم كل ما يكمن تقديمه ليس فقط للمستخدم العادي بل ولمدراء النظام (Administrators) بينما ما تكون نسخة الأجهزة الذكية مختصرة على التقارير ومتابعة واعتماد بعض إجراءات العمل وربما بعض الإدخالات البسيطة. بالمقابل فإن نسخة البرنامج والتي تعمل على الأجهزة الملبوسة مثل الساعات ستكتفي بالتنبيهات مثلا. ذلك يتطلب أن تستطيع واجهة التطبيق تقديم المساعدة للجميع.
طرق اتصال تطبيقات العميل لها دور أيضا مؤثر على واجهات التطبيق البرمجية تتمثل في الحرص على إرسال المعلومات التي يحتاجها تطبيق العميل بحجم يتناسب مع اتصاله. فإذا كان تطبيق العميل برنامج يعمل على سطح المكتب (Desktop App) فإنه عادة ما يكون جزء من شبكة شركة قادرة على إرسال معلومات كثيرة بدون حدود تذكر. بينما سيتعين على واجهة التطبيق إرسال معلومات أقل للتطبيق الذي يعمل على هاتف ذكي خارج أسوار الشركة ويتصل بالواجهة عن طريق شبكة مزود خدمة جوال ك 3جي أو 4جي.
يجب أن تكون بيئة استضافة واجهة التطبيق قادرة على توفير ما يحتاجه تطبيق العميل من خدمات لا وظيفية ولكن لها تأثير كبير على التطبيق. فمثلا يتعامل تطبيق الويب مع الواجهة بشكل أسرع بسبب وجودهما عادة في بيئة متقاربة حيث يصبح الاتصال من خادم إلى آخر وبالتالي يمكن لتطبيق الويب الاحتفاظ بمعلومات أقل بين الطلبات بسبب قدرة بيئة الواجهة التطبيقية على عمل تخزين مؤقت (Caching). بالمقابل فإن تطبيقات الهواتف الذكية ستضطر إلى تخزين مؤقت في الجهاز نفسه لأن الاتصال يحدث بين الهاتف العميل والخادم بطريقة أبطأ وستصبح مسؤولية واجهة التطبيق مختلفة هنا بحيث لا تتطلب بيئتها تخزين مؤقت بنفس الطريقة المذكورة في حالة تطبيق الويب.
يفرض نوع تطبيق العميل طريقة معينة للتأمين مثل تسجيل الدخول وغيره يتعين على واجهة التطبيق البرمجية دعمها. فإذا كان تطبيق الويب يحتاج إلى نوع معين من التأمين مثل استخدام Open Connect فإن تطبيقات العميل للهواتف الذكية عادة ما تحتاج إلى نوع مختلف من التأمين يدعى OAuth2. هذه أمثلة فقط لطرق التأمين ولكنها الأكثر شيوعا هذه الأيام.
طريقة التواصل الشائعة مع واجهات التطبيق: رست (REST)
رست ببساطة تعتمد على مفهوم بسيط وهو نقل حالة المورد (Resource) من الخادم إلى العميل وتحديث حالة هذا المورد من طلب إلى آخر. المورد هنا يمثله أي شيء مثل منتج أو سلة الشراء أو زبون مثلا. يتم طلب هذا المورد عن طريق استخدام أفعال HTTP. أي عند طلب استرداد مورد يقوم العميل بإرسال فعل Get إلى الخادم يحمل رقم المورد. وعند طلب كتابة مورد يقوم المورد بإرسال فعل Post وهكذا. أنظر إلى الشكل التالي:
متطلبات رست
يطلق على واجهات التطبيق البرمجية التي تحقق شروط رست وصف REST-ful. هناك 6 شروط يجب تحقيقها حتى يطلق الوصف المذكور سابقا على واجهة التطبيق. الشروط هي:
الخادم والعميل: ويقصد هنا أن التواصيل يتم بين خادم وعميل منفصلان ومنفصلان هنا لا تعني بالضرورة في جهازين مختلفين وإن كان هذا هو الشائع بالطبع. المهم الفصل الوظيفي الواضح بين الإثنين.
انعداميه الحالة: المقصود هنا أن الخادم لا يحتفظ بحالة المورد وأن حالة الطلب والمورد موجودة داخل الطلب نفسه بالكامل. فإذا ما تمت عدة طلبات بين الخادم والعميل فلا يجب أن يكون الخادم قد أحتفظ بأي شيء يدل على حالة آخر طلب مثلا. قارن ذلك ببعض الهياكل مثل RPC والتي كانت تعتمد على احتفاظ الخادم بحالة الجلسة (Session State).
الواجهة المنتظمة: أن يٌمثل المورد برابط (Uri) فريد وبسيط يٌعبر عن المورد مباشرة مثل /customers للمورد الذي يمثل الزبائن و /customers/20415 للزبون المٌمثل بالرقم 20415. ويتم الاعتماد على أفعال الـ HTTP لمعرفة المقصود من الطلب فمثلا GET ستسترجع الزبون السابق إذا تم طلبها على رابط الزبون و POST ستقوم بإدخاله على فرض عدم وجوده مسبقا وهكذا. يتضمن هذا خاصية يطلق عليها HATEOS وهي قدرة الخادم على إرسال روابط إضافية مع كل طلب تٌسهل على العميل تحديد ما يستطيع عمله بعد ذلك. هذا أقرب ما يكون عندما تزور صفحة ويب وترى جميع الروابط التي يمكن أن تضغط عليها لتأخذك من هذه الصفحة إلى التي بعدها.
نظام ذو طبقات: قد يكون اتصال العميل بالخادم مباشر أو عن طريق عدة طبقات وخوادم ولا يجب أن يغير هذا من طريقة اتصال العميل بالخادم. أي أن العميل لا يجب أن يعلم بهذا من أصله.
قابلية التخزين المؤقت: أن يكون هناك إمكانية لتخزين المورد في ذاكرة مؤقتة إذا كان المورد يقبل بذلك. يستطيع كل رد على طلب أن يحدد ذلك ويستطيع كل طلب أيضا أن يحدد ما إذا كان يريد تجاوز الذاكرة المؤقتة إذا كانت موجودة واسترجاع المورد من مكان تخزينه كقاعدة البيانات مثلا.
كود عند الطلب: هذا يعني ببساطة أن الخادم يستطيع أن يطور أو يخصص من وظائف العميل بإرسال كود. فمثلا لو كان العميل تطبيق ويب فإن الخادم يمكنه مثلا أن يرسل جافا سكريبت كود إلى العميل ليزيد من وظيفة العميل في حالة معينة. هذا الشرط خياري.
بسبب تعدد شروط الريست ومثالتيها في بعض النقاط، أصبح الكثير من الشركات ممن يقدم واجهات تطبيق برمجية مبنية على الويب بتجاهل بعضها بالرغم من إطلاق الجميع عليها أنها RESTful.
وفي الختام لا يمكن لأي تطبيق عصري يحتاج أن يكون مفتوح في وظائفه ويريد أن يتواجد على منصات متعددة أن يتجاهل بناء واجهة تطبيق برمجية له مبنية على الويب وخصوصا ريست. قد لا يستطيع المبرمج أن يتقيد بالكامل بما تمليه عليه رست من شروط ولكن وجود الأساسيات الصحيحة لواجهة التطبيق البرمجية من أول يوم هو شيء مهم جدا لأن تغيير الواجهة بعد استخدامها من قبل العملاء يجب أن يُدرس بعناية وينفذ بحذر.
المراجع
https://app.pluralsight.com/library/courses/web-api-design/table-of-contents
https://app.pluralsight.com/library/courses/building-securing-restful-api-aspdotnet/table-of-contents
http://whatisrest.com/rest_constraints/index
https://en.wikipedia.org/wiki/Representational_state_transfer