شرح rest api

REST API هي معمارية تفيد في بناء الموارد والاستعلام عنها بين خدمات الويب، وتحديدا كيف يتم تطبيق هذه الفلسفة في بروتوكول HTTP 

• REST هو اختصار ل Representational State Transfer أي كيف يمكن لنا أن نعبر عن شكل حالة ما وننقلها بين الخدمات.
• API تعني Application Programming Interface وهو الواجهة التي يتمكن من خلالها المستخدم الخارجي من ضبط والتأثير على الخدمة. 

دمج المصطلحين معا يعني أن توفر الخدمة واجهة برمجية API مبنية بطريقة REST يمكن للمستخدمين (أو الخدمات بين بعضها) التواصل عبرها عبر بروتوكول HTTP

يتم استخدامها في بناء واجهات النظم الخلفية عادة لاغلب الانظمة

يمكنك متابعة فيديو الشرح والقراءة عن REST أكثر عبر المقال التالي

يمكن تعريف الـ API , اختصارا لـ Application Programming Interface ترجمة عن واجهة تطبيقات برمجية أو الواجهة البرمجة للتطبيق , كـمجموع القواعد التي تحدد كيفية اتصال تطبيقات أو واجهات , أو حتى الأجهزة ببعضها البعض . شائع بناءها في تطبيقات الويب لفصل الواجهة الخلفية تماما عن شيفرات الواجهة الأمامية يتوفير نقاط وصول أو end points للوصول إلى مصادر معينة أو تطبيق أفعال CRUD بسهولة (Create, Read ,Update , Delete ) .  و يتم ذلك عن طريق إخفاء تعقيد منطق عمل وظيفة أو دالة أو تابع و تصدير طريقة بسيطة للوصول إليه و التعامل معه , يعطي هذا مرونة أكبر و قابلية أكثر للتحكم في التطبيق بواجهتيه : الأمامية و الخلفية .

أما عن REST API فهي واجهة برمجة تطبيقات تتوافق مع مبادئ تصميم REST ، أو كما يعرف بالـ representational state transfer architectural style . و لهذا السبب ، يُشار أحيانًا إلى واجهات برمجة تطبيقات REST إلى واجهات برمجة تطبيقات RESTful كصفة عن REST . 

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

على سبيل المثال : 

قد تستخدم واجهة برمجة تطبيقات REST كلا من التالي :

• طلب GET لاسترداد الموظفين في قاعدة بياناتنا .
• طلب POST لإنشاء موظف جديد .
• طلب PUT أو PATCH لتحديث بيانات موظف  .
• طلب DELETE لحذف بيانات موظف .

و يعبر عن ذلك بـ : 

GET https://your_domain.dm/api/v.x/teachers 

POST https://your_domain.dm/api/v.x/teachers

PATCH https://your_domain.dm/api/v.x/teachers/{teacher_id

DELETE https::/your_domain.dm/api/v.x/teachers/{teacher_id}

يتم وراء هاته الروابط أو النقاط سهلة الوصول إخفاء كل تعقيد , من الإتصال بقواعد البيانات و التحقق من الطلبية و معالجتها و إعادة الرد عليها . 

يمكن تلخيص مجموعة مبادئ REST التي تعطي صفة الـ RESTful لكل واجهة برمجية تلتزم بها كالتالي : 

• الواجهة الموحدة (uniform interface) : يجب أن تبدو جميع طلبيات واجهة برمجية ما للمورد نفسه بنفس الشكل متبعة نفس النسق , أي أن كل من الطلبات و الشكل العام لنقاط الوصول و الردود و غيرها يجب أن تتبع نسقا موحدا . 
• فصل واجهة العميل عن واجهة الخادم (Server - Client أو Client-server decoupling) : يفرض نمط تصميم عميل - خادم مبدأ فصل الاهتمامات التي تساعد مكونات العميل والخادم على التطور بشكل مستقل . و ذلك من خلال فصل اهتمامات واجهة المستخدم (العميل) عن اهتمامات تخزين و  معالجة البيانات (الخادم) . 
• عدمية الحالة (Stateless أو Statelessness) : يجب أن تكون واجهات برمجة تطبيقات REST عديمة الحالة ، مما يعني أن كل طلب يحتاج إلى تضمين جميع المعلومات اللازمة لمعالجته. بمعنى آخر ، لا تتطلب واجهات برمجة تطبيقات REST أي جلسات من جانب الخادم. لا يُسمح لتطبيقات الخادم بتخزين أي بيانات متعلقة بطلب العميل . 
• قابلية التخزين بشكل مؤقت (Cacheability أو Cacheable) :  بحيث يتطلب أن يتم تصنيف البيانات الموجودة في الاستجابة بشكل ضمني أو صريح على أنها قابلة للتخزين المؤقت أو غير قابلة للتخزين المؤقت . إذا كانت الاستجابة قابلة للتخزين المؤقت ، فسيتم منح تطبيق العميل الحق في إعادة استخدام بيانات الاستجابة لاحقًا ، للطلبات المكافئة ولفترة زمنية محددة . مثل : طلبات سجل الموظفين يتم تخزينها في الذاكرة المؤقتة و لا حاجة لإعادة تنفيذ الإستعلام إلا كل ساعة مثلا . في حين أن جلب معلومات سجل التعاملات أو المدفوعات غير قابل للتخزين بشكل مؤقت .  
• نظم الوسطاء (Layered system) : ففي REST APIs ، تمر  كل من المكالمات والاستجابات عبر طبقات مختلفة.  و كقاعدة عامة ، لا يفترض من تطبيقات العميل والخادم أن تتصل ببعضها البعض مباشرة. قد يكون هناك عدد من الوسطاء المختلفين في حلقة الاتصال. فيجب تصميم واجهات برمجة تطبيقات REST بحيث لا يمكن للعميل أو الخادم معرفة ما إذا كان يتواصل مع التطبيق النهائي أو الوسيط . مفاهيم مثل الطبقات الوسيطة أو الـ middlewares شائعة جدا بهذا الخصوص . 

يمكنك الإطلاع على هذا السؤال بشأن المبدأين Stateless و Cacheable هنا .

كما يمكنك التعرف أكثر على أسباب التوجه إلى تطوير الخدمات في الواجهات الخلفية كـ API هنا .