نموذج ريتشاردسون للنضج

📅 آخر تحديث: ٣١ يوليو ٢٠٢٦
✍️ نُشر في: ٣١ يوليو ٢٠٢٦
الموسوعة الحرة

نموذج ريتشاردسون للنضج ( RMM ) هو نموذج نضج اقترحه ليونارد ريتشاردسون عام 2008، ويصنف واجهات برمجة تطبيقات الويب (Web APIs) بناءً على مدى التزامها وتوافقها مع كل مستوى من مستويات النموذج الأربعة. ويهدف البحث في هذا النموذج، كما ذكر المؤلف، إلى استكشاف العلاقة بين قيود REST وأنواع خدمات الويب الأخرى. [ 1 ]

يقسم هذا النموذج الأجزاء الرئيسية لتصميم RESTful إلى ثلاث خطوات: تحديد الموارد ( URI )، وأفعال HTTP، وعناصر التحكم في الوسائط المتعددة (مثل الروابط التشعبية ). [ 2 ]

وقد أشير إلى أن نموذج RMM مفيد في تقييم جودة تصميم واجهات برمجة تطبيقات الويب RESTful على وجه الخصوص (على الرغم من أنه لا يقتصر على REST فقط)، وانتقد لعدم تناوله كيفية وصول النظام إلى أعلى مستويات نضج النموذج، فضلاً عن مراعاته لعدد محدود من سمات الجودة. [ 3 ]

ملخص

يمكن استخدام نموذج إدارة الموارد (RMM) لتحديد مدى التزام بنية خدمة الويب بمبادئ REST. يصنف هذا النموذج واجهة برمجة تطبيقات الويب إلى أربعة مستويات (من 0 إلى 3)، حيث يشير كل مستوى أعلى إلى التزام أكبر بتصميم REST. ويحتوي المستوى التالي أيضًا على جميع خصائص المستوى السابق. [ 4 ] [ 5 ]

توجد أيضًا أنظمة تصنيف أخرى لتصميم خدمات واجهة برمجة تطبيقات الويب، مثل CoHA و WS 3. [ 3 ]

المستويات

المستوى 0: مستنقع الجدري

يصف المستوى الأدنى من النموذج واجهة برمجة تطبيقات ويب (Web API) ذات معرّف موارد موحد (URI) واحد (عادةً POST عبر HTTP) يقبل جميع العمليات التي تدعمها الخدمة. لا يمكن تعريف الموارد بهذا الشكل تعريفًا دقيقًا. تتم المراسلة باستخدام XML أو JSON أو تنسيقات نصية أخرى. هذه هي خدمات RPC POX النموذجية والعديد من خدمات SOAP .

لا تُصنف أنظمة المستوى الصفري على أنها أنظمة RESTful .

أمثلة على واجهة برمجة التطبيقات من المستوى 0
معرّف الموارد الموحد (URI)فعل HTTPالعمليات
/bookingServicePOSTاسترجاع الوجهات/الفنادق/الغرف؛ إضافة/إلغاء حجز؛ إلخ.
/newsFeedServicePOSTاحصل على جميع الأخبار؛ احصل على جميع الأخبار في فئة محددة؛ احصل على جميع أخبار منفذ إخباري محدد؛ إلخ.

المستوى 1: الموارد

يُقدّم هذا النظام موارد ويسمح بطلبات إلى عناوين URI فردية (لا تزال جميعها عادةً من نوع POST) لإجراءات منفصلة بدلاً من عرض نقطة نهاية موحدة (API). لا تزال موارد API عامة، ولكن من الممكن تحديد نطاق كل منها.

تصميم المستوى الأول ليس متوافقًا مع REST، ولكنه ينظم واجهة برمجة التطبيقات في اتجاه أن تصبح كذلك.

أمثلة على واجهة برمجة التطبيقات من المستوى 1
معرّف الموارد الموحد (URI)فعل HTTPعملية
/bookingDestinationsPOSTاسترجاع الوجهات
/bookingReservationsPOSTإضافة/إلغاء الحجوزات
/bookingRoomsPOSTإضافة/إلغاء الطلبات الخاصة بالحجز
/bookingFeedbackPOSTاترك تقييم للخدمة

المستوى 2: أفعال HTTP

يبدأ النظام باستخدام أفعال HTTP . يتيح ذلك مزيدًا من التخصص للمورد، وبالتالي يُضيّق نطاق وظائف كل عملية على حدة داخل الخدمة. يتمثل الفصل الرئيسي على هذا المستوى في تقسيم المورد الواحد إلى قسمين: طلب للحصول على البيانات فقط (GET)، وطلب لتعديلها (POST). كما يُمكن تحقيق مزيد من التفصيل. طلبات GET تجلب البيانات فقط، بينما تُضيف طلبات POST/PUT بيانات جديدة وتُحدّث البيانات الموجودة، أما طلبات DELETE فتحذف أو تُبطل العمليات السابقة. من عيوب توفير خدمة موزعة بأكثر من أفعال GET وPOST لكل مورد، ازدياد تعقيد استخدام هذا النظام.

أمثلة على واجهة برمجة التطبيقات من المستوى الثاني
معرّف الموارد الموحد (URI)فعل HTTPعملية
/destinationsGETاسترجاع الوجهات
/reservationsGETالحصول على الحجوزات وفقًا لمعايير محددة
/reservationsPOSTإضافة/إلغاء الحجوزات
/roomsPOSTطلب إضافات للغرفة
/roomsDELETEإزالة الإضافات من الغرفة

المستوى 3: عناصر التحكم في الوسائط المتعددة

يُقدّم المستوى الأخير تمثيل الوسائط المتعددة. تُعرف هذه العناصر أيضًا باسم HATEOAS (الوسائط المتعددة كمحرك لحالة التطبيق)، وهي عناصر مُضمّنة في رسائل استجابة الموارد، تُتيح إنشاء علاقة بين كيانات البيانات الفردية المُعادة من واجهات برمجة التطبيقات والمُمرّرة إليها. على سبيل المثال، قد يُعيد طلب GET إلى نظام حجز فندقي عددًا من الغرف المتاحة، بالإضافة إلى روابط الوسائط المتعددة (والتي كانت في بدايات هذا النموذج عبارة عن عناصر تحكم روابط HTML)، مما يسمح للعميل بحجز غرف مُحدّدة.

هذا هو المستوى الأخير من نموذج ريتشاردسون للنضج.

طلب:

طلب GET إلى /room/?customerId=1&date=10-11-2020&hotelCode=ASTORIA HTTP / 1.1

إجابة:

{ "customerId" : "1" , "reservations" : [{ "room" : "102" , "checkin" : "10-11-2020" , "checkout" : "11-14-2020" , "price" : "100" , "href" : "https://localhost:8080/room/102" }] }

مراجع

  1. ↑ ريتشاردسون، ليونارد (20 نوفمبر 2008). "العدالة ستتطلب منا ملايين الخطوات المعقدة" . www.crummy.com . الفصل الثالث: الاستدلال بالنضج . تم الاطلاع عليه بتاريخ 19 مايو 2021 .{{cite web}}: رابط خارجي في |location=( مساعدة ) CS1 صيانة: موقع ( رابط )
  2. ↑ "نموذج ريتشاردسون للنضج" . martinfowler.com . تم الاطلاع عليه بتاريخ 10 ديسمبر 2020 .
  3. 1 2 إيفان سلفادوري، فرانك سيكويرا (يونيو 2015). "نموذج النضج لواجهات برمجة تطبيقات الويب RESTful الدلالية" . بوابة البحث.نت . تم الاسترجاع في 10 ديسمبر 2020 .
  4. ↑ هيرانيا جاياثيلاكا، تشاندرا كرينتز، وريتش وولسكي (2016). "الحوسبة الموجهة بالخدمات باستخدام واجهات برمجة التطبيقات: التحديات والاتجاهات الناشئة" (ملف PDF) . جامعة كاليفورنيا في سانتا باربرا، الولايات المتحدة الأمريكية . تاريخ الاطلاع: 11 ديسمبر 2020 .{{cite news}}: صيانة CS1: أسماء متعددة: قائمة المؤلفين ( رابط )
  5. ↑ آرني كوشيل، إيرينا أستروفا، ماكسيميليان بلانكشين، دومينيك شونر، وكيفن شولز (2019). "تقييم مدى توافق واجهات برمجة التطبيقات (APIs) مع معايير REST من خلال منهجية Rough"(ملف PDF) . وقائع المؤتمر الدولي الخامس عشر لأنظمة وتقنيات معلومات الويب (WEBIST 2019) . تم الاطلاع عليه بتاريخ 11 ديسمبر 2020 .{{cite news}}: صيانة CS1: أسماء متعددة: قائمة المؤلفين ( رابط )