FullStackRestful

ما هو REST— تفسير بسيط للمبتدئين، الجزء 2: قيود REST

كتب بواسطة: 15/12/2019 One Comment

هذا هو الجزء 2 من مقالتين تشرح المفاهيم الأساسية لـ REST. يشرح هذا الجزء 6 قيود لـ REST. اقرأ الجزء 1 هنا.

ولكي يكون برنامج برمجة التطبيقات (API) في RESTful يتعين عليه الالتزام ب 6 قيود:

  • واجهة موحدة (Uniform interface)
  • الفصل بين الخادم والعميل (Client — server separation)
  • عديم الحالة (Stateless)
  • نظام الطبقات (Layered system)
  • قابل للتخزين المؤقت (Cacheable)
  • تواجد الكود عند الطلب (Code-on-demand)

واجهة موحدة (Uniform interface)

هذا القيد لديه 4 أجزاء:

  1. يتوجب على الطلب المرسول للخادم ان يحتوي على مصدر يعرفه أي resource identifier. 
  2. الاستجابة التي يقوم بها الخادم (server) تتضمن معلومات كافية حتى يتمكن العميل (client) من تعديل المصدر.
  3. كل طلب إلى API يحتوي على جميع المعلومات التي يحتاج إليها الخادم (server)  لتنفيذ الطلب، كما تحتوي كل إستجابة يقوم الخادم (server) بإرجاعها على جميع المعلومات التي يحتاجها العميل (client)  لفهم الاستجابة.
  4. الوسائط الفائقة  اي الـ Hypermedia كمحرك لحالة التطبيق — قد يبدو هذا مُبهماً بعض الشيء، لذا دعونا نكسره: من خلال التطبيق، نعني تطبيق الويب الذي يقوم الخادم (server) بتشغيله. من خلال الوسائط الإعلامية الفائقة، نشير إلى الروابط التشعبية، أو ببساطة الروابط، التي يمكن للخادم تضمينها في الاستجابة. تعني الجملة بأكملها أن الخادم (server) يستطيع إبلاغ العميل (client)، في رد عن طريق تغيير حالة تطبيق الويب. إذا طلب العميل (client) مستخدماً معيناً، يستطيع الخادم (server) تقديم ليس حالة ذلك المستخدم فحسب بل أيضاً معلومات حول كيفية تغيير حالة المستخدم، مثل كيفية تحديث اسم المستخدم أو كيفية حذف المستخدم.

 من السهل التفكير في الطريقة التي يتم بها ذلك عن طريق التفكير في خادم (server)  يعيد إستجابة (response) بتنسيق HTML إلى المتصفح (وهو العميل). سيتضمن HTML علامات تمييز ذات روابط (هذا جزء الوسائط الفائقة) إلى صفحة ويب أخرى حيث يمكن تحديث المستخدم (على سبيل المثال رابط إلى صفحة “إعدادات الملف الشخصي”).

 لوضع كل هذا بعين الاعتبار، تقوم معظم صفحات الويب بتطبيق الوسائط الفائقة كمحرك لحالة التطبيق، ولكن أكثر واجهات برمجة التطبيقات (APIs)  شيوعاً لا تلتزم بهذا القيد. ولفهم هذا المفهوم بشكل أكبر، أنصح كثيراً بمشاهدة هذا الفيديو على يوتيوب لمدة 30 دقيقة.

نتيجة الواجهة الموحدة، هي أن الطلبات من زبائن مختلفين تبدو متشابهة، سواء كان العميل متصفح الـchrome، أو خادم linux أو سكربت python أو تطبيق أندرويد أو أي شيء آخر.

الفصل بين العميل والخادم (Client — server separation)

يعمل العميل (client) والخادم (server) بشكل مستقل، كل على حدة، ولا يكون التفاعل بينهما إلا في شكل طلبات يتقدم بها العميل (client) وحده، واستجابات يقوم الخادم (server) بإرسالها إلى العميل كرد فعل على طلب. يظل الخادم في انتظار طلبات العملاء (clients) القادمة. لا يبدأ الخادم في إرسال معلومات عن حالة بعض المصادر بمفرده.

عديم الحالة (stateless)

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

يحتوي كل طلب فردي على جميع المعلومات التي يحتاجها الخادم (server) لتنفيذ الطلب وإرجاع إستجابة، بغض النظر عن الطلبات الأخرى التي يقدمها نفس مستخدم واجهة برمجة التطبيقات (API).

نظام الطبقات

بين العميل (client) الذي يطلب تمثيل حالة المصدر والخادم (server) الذي يقوم بإرسال الاستجابة مرة أخرى، قد يكون هناك عدد من الخوادم (servers) في المنتصف. قد توفر هذه الخوادم (servers) طبقة أمان أو طبقة تخزين مؤقت أو طبقة موازنة الأحمال أو وظائف أخرى. يجب ألا تؤثر تلك الطبقات على الطلب أو الرد. العميل (client) لا يعرف عدد الطبقات، إن وجدت  بين العميل (client) والخادم (server) الفعلي الذي يستجيب للطلب.

قابل للتخزين المؤقت (Cacheable)

وهذا يعني أن البيانات التي يرسلها الخادم (server) تحتوي على معلومات حول ما إذا كانت البيانات قابلة للتخزين المؤقت أم لا. إذا كانت البيانات  قابلة للتخزين المؤقت، فقد تحتوي على نوع من رقم الإصدار. رقم الإصدار هو ما يجعل التخزين المؤقت ممكناً: وبما أن العميل (client) يعرف أي إصدار من البيانات لديه بالفعل (من إستجابة سابقة)، يمكن للعميل (client)  تجنب طلب نفس البيانات مراراً وتكراراً. كما يجب أن يعرف العميل (client) ما إذا كان الإصدار الحالي للبيانات منتهياً، وفي هذه الحالة سيعلم العميل (client) أنه يجب عليه إرسال طلب آخر إلى الخادم (server) للحصول على آخر البيانات حول حالة المصدر.

تواجد الكود عند الطلب (Code-on-demand)

هذا القيد اختياري — يمكن لواجهة برمجة التطبيقات (API) أن تكون RESTful حتى دون توفير كود حسب الطلب.

يمكن للعميل (client) طلب كود من الخادم (server)، ومن ثم فإن الرد من الخادم (server) سيتضمن بعض الأكواد، عادة في شكل نص تنفيذي (script)، عندما تكون الإستجابة بتنسيق HTML. عندئذٍ يستطيع العميل (client) تنفيذ ذلك الكود.

شارك في النقاش One Comment

اترك تعليق