واجهة برمجة تطبيقات REST هي واجهة برمجة التطبيقات (API) التي تتوافق مع مبادئ التصميم الخاصة ببنية نقل الحالة التمثيلية (REST)، وهو نمط يستخدم لربط أنظمة الوسائط التشعبية الموزعة. يشار إلى واجهات برمجة تطبيقات REST أحيانًا باسم واجهات برمجة تطبيقات RESTful أو واجهات برمجة تطبيقات الويب RESTful.
قدّم عالم الكمبيوتر Dr. Roy Fielding أول تعريف لمفهوم REST عام 2000 في أطروحته لنيل الدكتوراه. ويوفر REST للمطورين مستوى مرتفعًا نسبيًا من المرونة والاتساق وقابلية التوسع والكفاءة. كما تتيح واجهات REST البرمجية نهجًا خفيفًا لإنشاء واجهات برمجة تطبيقات الويب، وتُستخدم عادةً لتسهيل تبادل البيانات بين التطبيقات وخدمات الويب وقواعد البيانات، وربط المكونات ضمن بنى الخدمات المصغّرة.
في أبسط صورها، تُعَد واجهة برمجة التطبيقات (API) آلية تُتيح للتطبيق أو الخدمة الوصول إلى مورد داخل تطبيق آخر أو خدمة أو قاعدة بيانات. التطبيق أو الخدمة التي تصل إلى الموارد هي العميل، والتطبيق أو الخدمة التي تحتوي على الموارد هي الخادم.
تفرض بعض واجهات برمجة التطبيقات، مثل SOAP أو XML-RPC، إطار عمل صارمًا على المطورين. ولكن يمكن للمطورين تطوير واجهات برمجة تطبيقات REST باستخدام أي لغة برمجة تقريبًا ودعم تنسيقات بيانات مختلفة. الشرط الوحيد هو أن تتوافق مع مبادئ تصميم REST الستة التالية، والمعروفة أيضًا باسم قيود البنية.
يجب أن تكون جميع طلبات واجهة برمجة التطبيقات (API) للمورد نفسه متشابهة، بغض النظر عن مصدر الطلب. يجب أن تضمن واجهة برمجة التطبيقات REST API أن الجزء نفسه من البيانات، مثل الاسم أو عنوان البريد الإلكتروني للمستخدم، ينتمي إلى معرِّف واحد موحَّد للموارد (URI) فقط. يجب ألّا تكون الموارد كبيرة جدًا، ولكن يجب أن تحتوي على كل جزء من المعلومات التي قد يحتاجها العميل.
في تصميم واجهات برمجة تطبيقات REST، يجب أن تكون تطبيقات العميل والخادم مستقلة عن بعضها البعض. المعلومة الوحيدة التي يجب أن يعرفها تطبيق العميل هي معرّف المورّد الموحَّد (URI) للمورد المطلوب؛ لأنه لا يستطيع التفاعل مع تطبيق الخادم بأي طرق أخرى. وبالمثل، لا ينبغي أن يقوم تطبيق الخادم بتعديل تطبيق العميل بخلاف تمرير البيانات المطلوبة من خلال HTTP.
تُعَد واجهات برمجة التطبيقات REST غير حالية، ما يعني أن كل طلب يحتاج إلى تضمين جميع المعلومات اللازمة لمعالجته. بمعنى آخر، لا تتطلب واجهات برمجة تطبيقات REST أي جلسات من جانب الخادم. ولا يُسمح لتطبيقات الخادم بتخزين أي بيانات تتعلق بطلب العميل.
يجب أن تكون الموارد قابلة للتخزين المؤقت من جانب العميل أو الخادم، إذا كان ذلك ممكنًا. تحتاج استجابات الخادم أيضًا إلى احتواء معلومات حول إذا ما كان التخزين المؤقت مسموحًا به للمورد الذي تم تسليمه. والهدف هو تحسين الأداء من جانب العميل، مع زيادة قابلية التوسع من جانب الخادم.
في واجهات برمجة التطبيقات REST، تمر المكالمات والاستجابات عبر طبقات مختلفة. كقاعدة ذهبية، لا تفترض أن تطبيقات العميل والخادم متصلان مباشرة ببعضهما البعض. قد يكون هناك وسطاء مختلفون في حلقة الاتصال. يجب تصميم واجهات برمجة التطبيقات REST بحيث لا يستطيع كل من العميل أو الخادم معرفة إذا ما كانا يتواصلان مع التطبيق النهائي أو مع وسيط.
عادةً ما ترسل واجهات برمجة التطبيقات REST موارد ثابتة، ولكن في بعض الحالات، يمكن أن تحتوي الاستجابات أيضًا على تعليمات برمجية قابلة للتنفيذ (مثل تطبيقات Java). في هذه الحالات، يجب تشغيل الكود البرمجي عند الطلب فقط.
كُن مطَّلِعًا دومًا على أهم -وأكثر- توجُّهات الصناعة إلهامًا في الذكاء الاصطناعي والأتمتة والبيانات وغيرها، من خلال رسالة Think الإخبارية التي يتم إرسالها مرتين أسبوعيًا.راجِع بيان الخصوصية لشركة IBM.
تتواصل واجهات برمجة التطبيقات REST من خلال طلبات HTTP لأداء وظائف قاعدة البيانات القياسية مثل إنشاء السجلات وقراءتها وتحديثها وحذفها (المعروفة أيضًا باسم CRUD) داخل المورد.
على سبيل المثال، ستستخدِم واجهة برمجة التطبيقات REST طلب GET لاسترداد سجل. يُنشئ طلب "POST" سجلًا جديدًا. يحدِّث طلب "PUT" السجل، ويحذف طلب "DELETE" السجل. يمكن استخدام جميع أساليب HTTP في استدعاءات واجهة برمجة التطبيقات. تشبه واجهة برمجة التطبيقات REST المصممة جيدًا موقع ويب يعمل في متصفح ويب مزود بوظيفة HTTP مضمنة.
تُعرَف حالة المورد في أي لحظة معينة، أو الطابع الزمني، بأنها تمثيل المورد. يمكن تسليم هذه المعلومات إلى العميل بأي صيغة تقريبًا، بما في ذلك ترميز JavaScript Object Notation (اختصارًا JSON)، أو HTML، أو XLT، أو Python، أو PHP أو النص العادي. تحظى JSON بشعبية كبيرة لأنها قابلة للقراءة من قِبل كل من البشر والآلات، كما أنها لغة برمجة محايدة.
تُعَد رؤوس الطلبات والمَعلمات أيضًا مهمة في استدعاءات واجهات برمجة التطبيقات REST لأنها تحتوي على معلومات تعريفية مهمة مثل البيانات الوصفية، والتفويضات، ومعرِّفات الموارد الموحَّدة (URIs)، والتخزين المؤقت، وملفات تعريف الارتباط وغير ذلك. تُستخدم رؤوس الطلبات ورؤوس الاستجابات، إلى جانب أكواد حالة HTTP التقليدية، ضمن واجهات برمجة التطبيقات REST المصممة بشكل جيد.
مقارنة بين GraphQL وواجهة برمجة تطبيقات REST: ما الفرق بينهما؟
على الرغم من أن المرونة هي ميزة كبيرة لتصميم واجهة برمجة التطبيقات REST، إلا أن هذه المرونة نفسها تجعل من السهل تصميم واجهة برمجة تطبيقات معطلة أو ذات أداء ضعيف. لهذا السبب، يشارك المطورون المحترفون أفضل الممارسات في مواصفات REST API.
تحدِّد مواصفة OpenAPI (OAS) طريقة لوصف واجهة برمجة التطبيقات (API) بطريقة تُتيح لأي مطور أو تطبيق اكتشافها وفهم معاييرها وقدراتها بالكامل. تتضمن هذه المعلومات نقاط النهاية المتاحة والعمليات المسموح بها على كل نقطة نهاية، ومَعلمات العمليات، وطرق المصادقة، وغير ذلك. يتضمن أحدث إصدار، OAS3 أدوات عملية مثل OpenAPI Generator لإنشاء برامج عميلة لواجهات API وهياكل أولية للخوادم بلغات برمجة مختلفة.
يبدأ تأمين واجهة برمجة التطبيقات REST أيضًا من خلال تطبيق أفضل الممارسات المتبعة في المجال. استخدِم خوارزميات التجزئة لأمان كلمة المرور وHTTPS لنقل البيانات بشكل آمن. يمكن لإطار عمل الترخيص مثل OAuth 2.0أن يساعد على الحد من امتيازات تطبيقات الطرف الثالث.
باستخدام الطابع الزمني في رأس HTTP، يمكن لواجهة برمجة التطبيقات أيضًا رفض أي طلب يصل بعد فترة زمنية معينة. يُعَد التحقق من المَعلمات وJSON Web Tokens طريقتين أخريين لضمان وصول العملاء المصرح لهم فقط إلى واجهة برمجة التطبيقات.
استفِد من إمكانات الذكاء الاصطناعي والأتمتة لحل المشكلات بشكل استباقي عبر مجموعة التطبيقات.
استخدم أدوات وبرمجيات عمليات التطوير لإنشاء تطبيقات السحابة الأصلية ونشرها وإدارتها عبر أجهزة وبيئات متعددة.
عزّز مرونة أعمالك ونموها من خلال التحديث المستمر لتطبيقاتك على أي منصة، وذلك باستخدام خدمات الاستشارات السحابية التي نقدمها.