استراحة

REST ( Re presentational S state Transfer ) هو أسلوب معماري للبرمجيات تم إنشاؤه لتوجيه تصميم وتطوير بنية شبكة الويب العالمية . يحدد REST مجموعة من القيود حول كيفية تصرف بنية نظام الوسائط المتعددة الموزع على نطاق الإنترنت ، مثل الويب. يؤكد أسلوب REST المعماري على الواجهات الموحدة ، والنشر المستقل للمكونات ، وقابلية التوسع للتفاعلات بينها، وإنشاء بنية متعددة الطبقات لتعزيز التخزين المؤقت لتقليل زمن الوصول المتصور للمستخدم ، وفرض الأمان ، وتغليف الأنظمة القديمة . ^[1]

لقد تم استخدام REST في جميع أنحاء صناعة البرمجيات لإنشاء تطبيقات ويب موثوقة بدون جنسية . يمكن وصف التطبيق الذي يلتزم بالقيود المعمارية REST بشكل غير رسمي بأنه RESTful ، على الرغم من أن هذا المصطلح يرتبط بشكل أكثر شيوعًا بتصميم واجهات برمجة التطبيقات المستندة إلى HTTP وما يُعتبر على نطاق واسع أفضل الممارسات فيما يتعلق بـ "الأفعال" ( طرق HTTP ) التي يستجيب لها المورد بينما لا علاقة لها بـ REST كما صيغت في الأصل - وغالبًا ما تكون على خلاف مع المفهوم. ^[2]

تم تقديم مصطلح نقل الحالة التمثيلية وتعريفه في عام 2000 بواسطة عالم الكمبيوتر روي فيلدينج في أطروحته للدكتوراه. وهذا يعني أن الخادم سوف يستجيب بتمثيل أحد الموارد (اليوم، سيكون في أغلب الأحيان مستند HTML أو XML أو JSON ) وسوف يحتوي هذا المورد على روابط الوسائط المتعددة التي يمكن اتباعها لتغيير حالة النظام. أي طلب من هذا القبيل سوف يتلقى بدوره تمثيل أحد الموارد، وهكذا.

النتيجة المهمة هنا هي أن المعرف الوحيد الذي يتعين معرفته هو معرف المورد الأول المطلوب، وسيتم اكتشاف جميع المعرفات الأخرى. وهذا يعني أن هذه المعرفات يمكن أن تتغير دون الحاجة إلى إخطار العميل مسبقًا، وأنه لا يمكن أن يكون هناك سوى ارتباط غير محكم بين العميل والخادم.

بدأ استخدام الويب في الحياة اليومية في عامي 1993 و1994، عندما بدأت مواقع الويب للاستخدام العام في التوفر. ^[3] في ذلك الوقت، لم يكن هناك سوى وصف مجزأ لهندسة الويب، وكان هناك ضغط في الصناعة للاتفاق على بعض المعايير لبروتوكولات واجهة الويب. على سبيل المثال، تمت إضافة العديد من الامتدادات التجريبية إلى بروتوكول الاتصال (HTTP) لدعم الوكلاء ، وتم اقتراح المزيد من الامتدادات، ولكن كانت هناك حاجة إلى هندسة ويب رسمية لتقييم تأثير هذه التغييرات. ^[4]

بدأت مجموعات العمل التابعة لـ W3C و IETF العمل معًا على إنشاء أوصاف رسمية للمعايير الأساسية الثلاثة للويب: URI و HTTP و HTML . شارك روي فيلدينج في إنشاء هذه المعايير (على وجه التحديد HTTP 1.0 و1.1 وURI)، وخلال السنوات الست التالية أنشأ أسلوب REST المعماري، واختبر قيوده على معايير بروتوكول الويب واستخدمه كوسيلة لتحديد التحسينات المعمارية - وتحديد عدم التطابق المعماري. عرّف فيلدينج أسلوب REST في أطروحته للدكتوراه عام 2000 "الأنماط المعمارية وتصميم بنيات البرمجيات القائمة على الشبكات" ^{[1] [5]} في جامعة كاليفورنيا في إيرفين .

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

بطبيعتها، تكون الأنماط المعمارية مستقلة عن أي تنفيذ محدد، وبينما تم إنشاء REST كجزء من تطوير معايير الويب، فإن تنفيذ الويب لا يطيع كل قيد في نمط REST المعماري. يمكن أن تحدث عدم التطابق بسبب الجهل أو السهو، ولكن وجود نمط REST المعماري يعني أنه يمكن تحديدها قبل أن تصبح موحدة. على سبيل المثال، حدد فيلدينج تضمين معلومات الجلسة في عناوين URI على أنه انتهاك لقيود REST والتي يمكن أن تؤثر سلبًا على التخزين المؤقت المشترك وقابلية توسيع الخادم. كما انتهكت ملفات تعريف الارتباط HTTP قيود REST ^{[4] لأنها يمكن أن تصبح غير متزامنة مع حالة تطبيق المتصفح،} مما يجعلها غير موثوقة؛ كما أنها تحتوي على بيانات غير شفافة يمكن أن تكون مصدر قلق للخصوصية والأمان .

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

إن الفصل القوي بين العميل والخادم مع نقل المعلومات المستند إلى النص باستخدام بروتوكول عنونة موحد وفر الأساس لتلبية متطلبات الويب: قابلية التوسع ، وقابلية التوسع الفوضوي ^{[ بحاجة لمصدر ]} والنشر المستقل للمكونات، ونقل البيانات على نطاق واسع، وحاجز دخول منخفض لقراء المحتوى ومؤلفي المحتوى والمطورين.

تؤثر قيود النمط المعماري REST على الخصائص المعمارية التالية: ^{[1] [6]}

• الأداء في تفاعلات المكونات، والذي يمكن أن يكون العامل المهيمن في الأداء المتصور للمستخدم وكفاءة الشبكة؛ ^[7]
• إمكانية التوسع مما يسمح بدعم أعداد كبيرة من المكونات والتفاعلات بين المكونات؛
• بساطة الواجهة الموحدة؛
• إمكانية تعديل المكونات لتلبية الاحتياجات المتغيرة (حتى أثناء تشغيل التطبيق)؛
• إمكانية رؤية الاتصالات بين المكونات من خلال وكلاء الخدمة؛
• إمكانية نقل المكونات عن طريق نقل الكود البرمجي مع البيانات؛
• الموثوقية في مقاومة الفشل على مستوى النظام في وجود أعطال داخل المكونات أو الموصلات أو البيانات. ^[7]

يحدد نمط REST المعماري ستة قيود توجيهية. ^{[6] [8]} عندما يتم تطبيق هذه القيود على بنية النظام، فإنها تكتسب خصائص غير وظيفية مرغوبة ، مثل الأداء وقابلية التوسع والبساطة وإمكانية التعديل والرؤية وقابلية النقل والموثوقية. ^[1]

القيود الرسمية لـ REST هي كما يلي: ^[9]

• العميل/الخادم – يتم فصل العملاء عن الخوادم من خلال واجهة محددة جيدًا
• عديم الجنسية – لا يستهلك العميل المحدد مساحة تخزين الخادم عندما يكون العميل "في حالة سكون"
• ذاكرة التخزين المؤقت - تشير الاستجابات إلى إمكانية تخزينها مؤقتًا
• واجهة موحدة
• النظام الطبقي - لا يستطيع العميل عادةً معرفة ما إذا كان متصلاً مباشرة بالخادم النهائي، أو بوسيط على طول الطريق
• الكود عند الطلب (اختياري) - تتمكن الخوادم من تمديد أو تخصيص وظائف العميل مؤقتًا عن طريق نقل المنطق إلى العميل والذي يمكن تنفيذه داخل جهاز افتراضي قياسي

يعد قيد الواجهة الموحدة أمرًا أساسيًا لتصميم أي نظام RESTful. ^[1] فهو يبسط ويفصل البنية، مما يمكّن كل جزء من التطور بشكل مستقل. القيود الأربعة لهذه الواجهة الموحدة هي:

• تحديد الموارد في الطلبات: يتم تحديد الموارد الفردية في الطلبات باستخدام عناوين URI . الموارد نفسها منفصلة مفهوميًا عن التمثيلات التي يتم إرجاعها إلى العميل. على سبيل المثال، يمكن للخادم إرسال البيانات من قاعدة البيانات الخاصة به بتنسيق HTML أو XML أو JSON — ولا يعد أي منها التمثيل الداخلي للخادم.
• التلاعب بالموارد من خلال التمثيلات: عندما يحتفظ العميل بتمثيل لمورد، بما في ذلك أي بيانات وصفية مرفقة، فإنه يكون لديه معلومات كافية لتعديل حالة المورد أو حذفها.
• الرسائل التي تصف نفسها بنفسها: تتضمن كل رسالة معلومات كافية لوصف كيفية معالجة الرسالة. على سبيل المثال، يمكن تحديد المحلل الذي سيتم استدعاؤه من خلال نوع الوسائط . ^[1]
• الوسائط الفائقة كمحرك لحالة التطبيق ( HATEOAS ) - بعد الوصول إلى عنوان URI الأولي لتطبيق REST - على غرار مستخدم الويب البشري الذي يصل إلى الصفحة الرئيسية لموقع ويب - يجب أن يكون عميل REST قادرًا على استخدام الروابط التي يوفرها الخادم ديناميكيًا لاكتشاف جميع الموارد المتاحة التي يحتاجها. مع استمرار الوصول، يستجيب الخادم بنص يتضمن ارتباطات تشعبية إلى موارد أخرى متاحة حاليًا. ليست هناك حاجة إلى أن يكون العميل مبرمجًا بشكل ثابت بمعلومات تتعلق ببنية الخادم. ^[10]

تم تطوير العديد من النماذج للمساعدة في تصنيف واجهات برمجة تطبيقات REST وفقًا لالتزامها بمبادئ مختلفة لتصميم REST، مثل

• نموذج ريتشاردسون للنضج
• تصنيف واجهات برمجة التطبيقات المستندة إلى HTTP ^[11]
• نموذج النضج WS ^{3 [12]}

• عنوان URL النظيف  – عنوان URL يهدف إلى تحسين قابلية استخدام موقع الويب
• شبكة توصيل المحتوى  – طبقة في النظام البيئي للإنترنت تعالج الاختناقات
• بروتوكول تطبيق المجال (DAP)
• قائمة مخططات URI  – معرف مساحة الأسماء المعين بواسطة IANA
• الخدمات المصغرة  – مجموعة من الخدمات المرتبطة بشكل فضفاض والتي تستخدم لبناء تطبيقات الكمبيوتر
• نظرة عامة على لغات وصف واجهة برمجة التطبيقات RESTful  – أوصاف واجهات الشبكة الحاسوبيةالصفحات التي تعرض أوصاف ويكي بيانات كبديل
• الهندسة المعمارية الموجهة للموارد  – النمط المعماري في تصميم البرمجيات
• الحوسبة الموجهة للموارد  – النمط المعماري في تصميم البرمجيات
• الهندسة المعمارية الموجهة نحو الخدمة  – النمط المعماري في تصميم البرمجيات
• الهندسة المعمارية الموجهة نحو الويب  – النمط المعماري في تصميم البرمجيات
• خدمات الويب  – خدمة يتم تقديمها بين الأجهزة الإلكترونية عبر الإنترنتالصفحات التي تعرض أوصافًا مختصرة لأهداف إعادة التوجيه

• باوتاسو، سيزار؛ وايلد، إريك؛ ألاركون، روزا (2014)، REST: مواضيع بحثية متقدمة وتطبيقات عملية، سبرينغر، رقم ISBN 9781461492986
• باوتاسو، سيزار؛ زيمرمان، أولاف؛ ليمان، فرانك (أبريل 2008)، "خدمات الويب الهادئة مقابل خدمات الويب "الكبيرة"، وقائع المؤتمر الدولي السابع عشر حول شبكة الويب العالمية، ص 805-814، doi :10.1145/1367497.1367606، ISBN 9781605580852، S2CID  207167438
• فيريرا ، أوتافيو (نوفمبر 2009)، خدمات الويب الدلالية: نهج مريح، IADIS، ISBN 978-972-8924-93-5
• فاولر، مارتن (2010-03-18). "نموذج ريتشاردسون للنضج: خطوات نحو مجد REST". martinfowler.com . تم الاسترجاع في 2017-06-26 .