ما المقصود بواجهة برمجة التطبيقات لبنية نقل الحالة التماثلية (REST API)؟

أولًا، تم تعريف REST في عام 2000 من قِبل عالم الحاسوب الدكتور Roy Fielding في أطروحته للدكتوراه، وتوفِّر REST مستوى عاليًا نسبيًا من المرونة، وقابلية التوسع، والكفاءة للمطورين. ولهذه الأسباب، ظهرت واجهات برمجة التطبيقات REST كطريقة شائعة لتوصيل المكونات والتطبيقات في بنية الخدمات المصغرة.

في أبسط صورها، تُعَد واجهة برمجة التطبيقات (API) آلية تُتيح للتطبيق أو الخدمة الوصول إلى مورد داخل تطبيق أو خدمة أخرى. التطبيق أو الخدمة التي تصل إلى الموارد هي العميل، والتطبيق أو الخدمة التي تحتوي على الموارد هي الخادم. تفرض بعض واجهات برمجة التطبيقات، مثل SOAP أو XML-RPC، إطار عمل صارمًا على المطورين. ولكن يمكن للمطورين تطوير واجهات برمجة تطبيقات REST باستخدام أي لغة برمجة تقريبًا ودعم مجموعة متنوعة من تنسيقات البيانات. الشرط الوحيد هو أن تتوافق مع مبادئ تصميم REST الستة التالية، والمعروفة أيضًا باسم القيود المعمارية.

يجب أن تكون جميع طلبات واجهة برمجة التطبيقات (API) للمورد نفسه متشابهة، بغض النظر عن مصدر الطلب. يجب أن تضمن واجهة برمجة التطبيقات REST API أن الجزء نفسه من البيانات، مثل الاسم أو عنوان البريد الإلكتروني للمستخدم، ينتمي إلى معرِّف واحد موحَّد للموارد (URI) فقط. يجب ألّا تكون الموارد كبيرة جدًا، ولكن يجب أن تحتوي على كل جزء من المعلومات التي قد يحتاجها العميل.

في تصميم واجهات برمجة التطبيقات REST، يجب أن تكون تطبيقات العميل والخادم مستقلة تمامًا عن بعضها. المعلومة الوحيدة التي يجب أن يعرفها تطبيق العميل هي معرّف المورّد الموحَّد (URI) للمورد المطلوب؛ لأنه لا يستطيع التفاعل مع تطبيق الخادم بأي طرق أخرى. وبالمثل، يجب ألّا يقوم تطبيق الخادم بتعديل تطبيق العميل بخلاف تمرير البيانات المطلوبة عبر بروتوكول HTTP.

تُعَد واجهات برمجة التطبيقات REST غير حالية، ما يعني أن كل طلب يحتاج إلى تضمين جميع المعلومات اللازمة لمعالجته. بمعنى آخر، لا تتطلب واجهات برمجة تطبيقات REST أي جلسات من جانب الخادم. ولا يُسمح لتطبيقات الخادم بتخزين أي بيانات تتعلق بطلب العميل.

يجب أن تكون الموارد قابلة للتخزين المؤقت من جانب العميل أو الخادم، إذا كان ذلك ممكنًا. تحتاج استجابات الخادم أيضًا إلى احتواء معلومات حول إذا ما كان التخزين المؤقت مسموحًا به للمورد الذي تم تسليمه. والهدف هو تحسين الأداء من جانب العميل، مع زيادة قابلية التوسع من جانب الخادم.

في واجهات برمجة التطبيقات REST، تمر المكالمات والاستجابات عبر طبقات مختلفة. كقاعدة عامة، لا تفترض أن تطبيق العميل والخادم يتصلان ببعضهما مباشرة. قد يكون هناك عدد من الوسطاء المختلفين في حلقة الاتصال. يجب تصميم واجهات برمجة التطبيقات REST بحيث لا يستطيع كل من العميل أو الخادم معرفة إذا ما كانا يتواصلان مع التطبيق النهائي أو مع وسيط.

عادةً ما ترسل واجهات برمجة التطبيقات REST موارد ثابتة، ولكن في بعض الحالات، يمكن أن تحتوي الاستجابات أيضًا على تعليمات برمجية قابلة للتنفيذ (مثل تطبيقات Java). في هذه الحالات، يجب تشغيل التعليمات البرمجية عند الطلب فقط.

تتواصل واجهات برمجة التطبيقات REST من خلال طلبات HTTP لأداء وظائف قاعدة البيانات القياسية مثل إنشاء السجلات وقراءتها وتحديثها وحذفها (المعروفة أيضًا باسم CRUD) داخل المورد.

على سبيل المثال، ستستخدِم واجهة برمجة التطبيقات REST طلب GET لاسترداد سجل. يُنشئ طلب "POST" سجلًا جديدًا. يحدِّث طلب "PUT" السجل، ويحذف طلب "DELETE" السجل. يمكن استخدام جميع أساليب HTTP في استدعاءات واجهة برمجة التطبيقات. تشبه واجهة برمجة التطبيقات REST المصممة جيدًا موقع ويب يعمل في متصفح ويب مزود بوظيفة HTTP مضمنة.

تُعرَف حالة المورد في أي لحظة معينة، أو الطابع الزمني، بأنها تمثيل المورد. يمكن تسليم هذه المعلومات إلى العميل بأي صيغة تقريبًا، بما في ذلك ترميز JavaScript Object Notation (اختصارًا JSON)، أو HTML، أو XLT، أو Python، أو PHP أو النص العادي. يُعَد JSON شائعًا لأنه قابل للقراءة من قِبَل كلٍّ من البشر والآلات، كما أنه مستقل عن لغات البرمجة.

تُعَد رؤوس الطلبات والمَعلمات أيضًا مهمة في استدعاءات واجهات برمجة التطبيقات REST لأنها تحتوي على معلومات تعريفية مهمة مثل البيانات الوصفية، والتفويضات، ومعرِّفات الموارد الموحَّدة (URIs)، والتخزين المؤقت، وملفات تعريف الارتباط وغير ذلك. تُستخدم رؤوس الطلبات ورؤوس الاستجابات، إلى جانب أكواد حالة HTTP التقليدية، ضمن واجهات برمجة التطبيقات REST المصممة بشكل جيد.

على الرغم من أن المرونة هي ميزة كبيرة في تصميم واجهات برمجة التطبيقات REST، إلا أن هذه المرونة نفسها تجعل من السهل تصميم واجهة برمجة تطبيقات معطلة أو ذات أداء ضعيف. لهذا السبب، يشارك المطورون المحترفون أفضل الممارسات في مواصفات REST API.

تحدِّد مواصفة OpenAPI (OAS) واجهة لوصف واجهة برمجة التطبيقات (API) بطريقة تُتيح لأي مطور أو تطبيق اكتشافها وفهم معاييرها وقدراتها بالكامل. تتضمن هذه المعلومات نقاط النهاية المتاحة والعمليات المسموح بها على كل نقطة نهاية، ومَعلمات العمليات، وطرق المصادقة، وغير ذلك. تتضمن النسخة الأحدث، OAS3 أدوات عملية مثل مولد OpenAPI لإنشاء عملاء واجهات برمجة التطبيقات وأكواد خوادم بلغات برمجة مختلفة.

يبدأ تأمين واجهة برمجة التطبيقات REST أيضًا من خلال تطبيق أفضل الممارسات المتبعة في المجال. استخدِم خوارزميات التجزئة لأمان كلمة المرور وHTTPS لنقل البيانات بشكل آمن. يمكن لإطار عمل الترخيص مثل OAuth 2.0 أن يساعد على الحد من امتيازات تطبيقات الطرف الثالث.

باستخدام الطابع الزمني في رأس HTTP، يمكن لواجهة برمجة التطبيقات أيضًا رفض أي طلب يصل بعد فترة زمنية معينة. يُعَد التحقق من المَعلمات وJSON Web Tokens طريقتين أخريين لضمان وصول العملاء المصرح لهم فقط إلى واجهة برمجة التطبيقات.