فوائد تبني نمط RESTful: ما هو REST ولماذا يجب أن تتعلمه؟

في هذا المقال، سنتعمق في مبادئ Representational State Transfer (REST) لنفهم ماهيتها والفوائد التي يمكنك جنيها من تطبيقها. من المهم أن ندرك دائمًا سبب تعلم أي شيء، وهذا يشمل REST. لذا، دعنا نستكشف ما تقدمه مبادئ REST لعالم تطوير الويب.

ما هو REST؟

Representational State Transfer (REST) هو نمط معماري (architectural style) اكتسب شعبية هائلة في السنوات الأخيرة بفضل بساطته وقابليته للتوسع. قبل أن يحظى REST بهذه الشعبية، كان SOAP هو الطريقة الافتراضية (de-facto) للوصول إلى الموارد والتواصل عبر الويب.

لماذا يجب أن تهتم بـ REST؟

في هذا القسم، سنسلط الضوء على أهمية مبادئ REST ولماذا يستحق الأمر بذل الجهد لتعلم المزيد عنها. ستتعلم أيضًا كيفية تطبيقها في مشاريع الواجهة الخلفية (backend projects) الخاصة بك.

1) REST سهل الفهم والتطبيق

صُمم REST ليعمل عبر بروتوكول HTTP (في الواقع، تأثر HTTP بـ REST). لذلك، فإنه يستفيد من أفعال HTTP verbs التي يعرفها معظمنا، مثل GET و POST و PUT. حتى لو لم تكن على دراية كاملة بهذه الأفعال، فإن أسماءها واضحة بذاتها.

كما أن الفصل الواضح بين كود العميل (client code) وكود الخادم (server code) يسهل على الفرق المختلفة العمل على أجزاء مختلفة من التطبيقات (الواجهة الأمامية front end أو الواجهة الخلفية back end). نظرًا لسهولة فهمه وتطبيقه، يمكن لمبادئ REST أن تساعد في زيادة إنتاجية فريق التطوير (dev team) الخاص بك.

تعتبر هذه المبادئ مهمة أيضًا إذا كنت تخطط لإصدار واجهة برمجة تطبيقات عامة (public API) ليقوم المطورون الآخرون ببناء تطبيقات باستخدامها. يعرف العديد من الأشخاص REST و HTTP، مما يسهل عليهم فهم واجهة API الخاصة بك واستخدامها.

2) REST يجعل تطبيقك أكثر قابلية للتوسع

هناك سببان رئيسيان وراء مساهمة REST في جعل تطبيقك أكثر قابلية للتوسع:

عدم الاحتفاظ بالحالة (No State)

كما سنرى في قسم لاحق (مبادئ REST)، أحد المبادئ الأساسية لـ REST هو أنه عديم الحالة (stateless) من جانب الخادم (server-side). لذلك، تتم معالجة كل طلب بشكل مستقل عن الطلبات السابقة. في التطبيقات التي تحتفظ بحالة من جانب الخادم (server-side state) أو الجلسات (sessions)، يتم تخزين جلسة (session) لكل مستخدم مسجل الدخول.

يمكن أن تتضخم بيانات هذه الجلسة بسهولة وتبدأ في استهلاك الكثير من الموارد (resources) على الخادم. من ناحية أخرى، تحتفظ الخوادم عديمة الحالة (stateless servers) بالموارد (الذاكرة memory) مشغولة فقط عند معالجة طلب، وتطلقها بمجرد معالجة الطلب.

نظرًا لأن الاتجاه الحالي في قابلية التوسع هو التوسع الأفقي (horizontal scaling) (عادةً في السحابة cloud)، فإن تخزين جلسات جانب الخادم (server-side sessions) يمكن أن يجعل توسيع نطاق تطبيقك صعبًا لأنه يخلق بعض المشاكل المعقدة. على سبيل المثال، لنفترض أن لديك العديد من الخوادم التي تعمل خلف موازن تحميل (load balancer). ماذا سيحدث إذا وصل العميل (client) إلى server1 في طلبه الأول (الآن server1 لديه جلسة العميل)، وفي وقت لاحق، وبسبب الحمل على server1، وصل العميل إلى server2 الذي لا يعرف بيانات جلسته السابقة التي تم تخزينها على server1؟ بالطبع، لهذه المشكلة حلول، لكنها تجعل قابلية التوسع أكثر صعوبة.

تنسيق أسرع لتبادل البيانات (Faster Data Interchange Format)

تستخدم واجهات API من نمط RESTful APIs عادةً JSON كتنسيق لتبادل البيانات (data interchange format). يعتبر JSON أكثر إحكامًا وأصغر حجمًا بكثير مقارنة بـ XML. كما يمكن تحليله (parsed) بشكل أسرع من XML. بينما تعمل واجهات REST APIs في الغالب مع JSON، يجب أن تضع في اعتبارك أنها لا تزال قادرة على الاستجابة بتنسيقات مختلفة باستخدام رأس Accept header.

3) التخزين المؤقت (Caching) أسهل مع REST

يُعد التخزين المؤقت (Caching) عاملًا حاسمًا في قابلية التوسع وأداء تطبيقات الويب الحديثة. يمكن لآلية تخزين مؤقت (cache mechanism) راسخة (بأفضل معدلات إصابة hit-rates ممكنة) أن تقلل بشكل كبير من متوسط وقت استجابة الخادم الخاص بك.

يهدف REST إلى تسهيل التخزين المؤقت. نظرًا لأن الخادم عديم الحالة (stateless) ويمكن معالجة كل طلب بشكل فردي، يجب أن تعيد طلبات GET requests عادةً نفس الاستجابة بغض النظر عن الطلبات السابقة والجلسة. هذا يجعل طلبات GET requests قابلة للتخزين المؤقت (cacheable) بسهولة، وعادةً ما تتعامل المتصفحات معها على هذا النحو. يمكننا أيضًا جعل طلبات POST requests قابلة للتخزين المؤقت باستخدام رأسي Cache-Control و Expires headers.

4) REST مرن

بالمرونة، أعني أنه سهل التعديل، وقادر أيضًا على الاستجابة للعديد من العملاء الذين قد يطلبون أنواعًا مختلفة من البيانات (مثل XML و JSON وما إلى ذلك). يمكن للعميل تحديد النوع باستخدام رأس Accept header (كما ذكرت سابقًا)، ويمكن لواجهة REST API أن تعيد استجابات مختلفة اعتمادًا على ذلك.

هناك آلية أخرى تستحق الذكر وهي HATEOAS. إذا لم تكن تعرف هذا المصطلح، فلا تقلق، فهو يعني ببساطة: “إرجاع عناوين URLs ذات الصلة في استجابة الخادم لمورد معين”.

لنلقِ نظرة على هذا المثال من ويكيبيديا. يطلب العميل معلومات الحساب باستخدام account_number من واجهة API بنكية ويتلقى هذه الاستجابة:

{
  "account" : {
    "account_number" : 12345 ,
    "balance" : {
      "currency" : "usd" ,
      "value" : 100.00
    },
    "links" : {
      "deposit" : "/accounts/12345/deposit" ,
      "withdraw" : "/accounts/12345/withdraw" ,
      "transfer" : "/accounts/12345/transfer" ,
      "close" : "/accounts/12345/close"
    }
  }
}

يستخدم هذا الخادم HATEOAS ويعيد الروابط للإجراءات المقابلة. هذا يجعل استكشاف واجهة API سهلًا للغاية، ويجعلها مرنة أيضًا من خلال السماح للخادم بتغيير نقاط النهاية (endpoints).

فكر في الأمر على هذا النحو: لو لم يكن الخادم يطبق HATEOAS، لاحتاج العميل إلى ترميز نقاط النهاية (hardcode the endpoints) بشكل ثابت مثل "/accounts/:account-id/deposit". ولكن إذا قام الخادم بتغيير عنوان URL إلى "/accounts/:account-id/depositMoney"، فسيحتاج كود العميل (client code) أيضًا إلى التغيير. بمساعدة روابط HATEOAS، يمكن للعميل التحقق من الرابط عن طريق تحليل JSON هذا وإجراء الطلب بسهولة. إذا تغيرت نقطة النهاية، فسيتم تزويدهم بالنقطة الجديدة، دون الحاجة إلى تغيير كود العميل.

الخاتمة

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