rest - شرح - wsdl




نقل الحالة التمثيلية(REST) وبروتوكول الوصول إلى الكائنات البسيطة(SOAP) (10)

شرح بسيط حول SOAP و REST

SOAP - "Simple Object Access Protocol"

يعد SOAP طريقة لنقل الرسائل أو كميات صغيرة من المعلومات عبر الإنترنت. يتم تنسيق رسائل SOAP في XML ويتم إرسالها عادةً باستخدام HTTP (بروتوكول نقل النص التشعبي).

الباقي - نقل الحالة التمثيلي

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

هل يمكن لأي شخص أن يفسر ما هو REST وما هو SOAP باللغة الإنجليزية البسيطة؟ وكيف تعمل خدمات الويب؟


REST هو نمط هندسة لتصميم التطبيقات المتصلة بالشبكة. تتمثل الفكرة في أنه بدلاً من استخدام آليات معقدة مثل CORBA أو RPC أو SOAP للاتصال بين الأجهزة ، يتم استخدام HTTP البسيط لإجراء مكالمات بين الأجهزة.


أنا أحب جواب بريان ر. أردت فقط أن أضيف أن ويكيبيديا تقدم وصفا واضحا ل REST . المادة يميزها عن SOAP.

REST هو تبادل معلومات الدولة ، القيام به ببساطة قدر الإمكان.

SOAP هو بروتوكول رسائل يستخدم XML.

أحد الأسباب الرئيسية التي تحول العديد من الأشخاص من SOAP إلى REST هو أن معايير WS-* (تسمى WS splat) المرتبطة بخدمات الويب التي تعتمد على SOAP معقدة للغاية. انظر wikipedia للحصول على قائمة بالمواصفات. كل من هذه المواصفات معقدة للغاية.

تعديل: لسبب ما لا يتم عرض الروابط بشكل صحيح. REST = REST

WS- * = http://en.wikipedia.org/wiki/WS- *


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


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

لا يزال بإمكاننا ربط SOAP بـ XMLbased Remote Procedure Calls ، ولكن تقنية SOAPbased Web Services ظهرت في نموذج مرن وقوي للمراسلة.

يفترض SOAP أن جميع الأنظمة مستقلة ولا يوجد نظام لديه أي معرفة بالوظائف الداخلية لوظائف داخلية أخرى. معظم هذه الأنظمة يمكن أن تفعله هو إرسال الرسائل إلى بعضها البعض ، ونأمل أن يتم اتخاذ إجراءات بشأنها. تنشر الأنظمة العقود التي يتعهدون بها ، بينما تعتمد الأنظمة الأخرى على هذه العقود لتبادل الرسائل معها.

تُسمى العقود بين الأنظمة بشكل جماعي البيانات الوصفية ، وتتضمن وصف الخدمة ، وأنماط تبادل الرسائل المدعومة والسياسات التي تحكم صفات الخدمة (قد تحتاج الخدمة إلى تشفيرها ، وتسليمها بشكل موثوق ، إلخ.) وصف الخدمة ، بدوره ، مفصل مواصفات البيانات (وثائق الرسالة) التي سيتم إرسالها واستلامها من قبل النظام. يتم وصف المستندات باستخدام لغة وصف XML مثل XML Schema Definition. وطالما أن جميع الأنظمة تحترم عقودها المنشورة ، فإنها يمكن أن تعمل فيما بينها ، كما أن التغييرات التي تطرأ على الأنظمة الداخلية لا تؤثر أبدًا على أي نظام آخر. كل نظام مسؤول عن ترجمة تطبيقاته الداخلية من وإلى عقوده

REST - نقل ملكية تمثيلي. البروتوكول المادي هو HTTP. أساسا ، REST هو أن جميع الموارد المتميزة على شبكة الإنترنت التي يمكن التعرف عليها بشكل فريد عن طريق عنوان URL. يمكن وصف جميع العمليات التي يمكن إجراؤها على هذه الموارد من خلال مجموعة محدودة من الأفعال (أفعال "CRUD") والتي بدورها تقوم بالتعيين إلى أفعال HTTP.

REST هو "الوزن الثقيل" أقل بكثير من SOAP.

العمل من خدمة الويب


هذا هو أبسط تفسير يمكن أن تجده في أي وقت.

يأخذ هذا المقال الزوج إلى زوجته السرد ، حيث يشرح الزوج لزوجته عن REST ، في الشروط العادية البحتة. يجب أن يقرأ!

how-i-explained-rest-to-my-wife (الرابط الأصلي)
how-i-explained-rest-to-my-wife (2013-07-19 رابط العمل)


يشير كل من SOAP و REST إلى طرق الأنظمة المختلفة للتحدث مع بعضهما البعض.

يستخدم REST ذلك باستخدام تقنيات تشبه الاتصال الذي يمتلكه متصفحك مع خوادم الويب: باستخدام GET لطلب صفحة ويب ، أو POST في حقول النماذج ، إلخ.

يوفر SOAP شيئًا مشابهًا ولكنه يفعل كل شيء من خلال إرسال كتل XML إلى الأمام والخلف. مكون أساسي آخر في SOAP هو WSDL وهو مستند XML يصف ما هي الوظائف وعناصر البيانات المدعومة. يمكن استخدام WSDLs للبرمجيا "اكتشاف" ما هي الوظائف المدعومة وكذلك لإنشاء stubs التعليمات البرمجية للبرمجة.


يمكن أن تستخدم كل من خدمات الويب SOAP و REST webservices بروتوكول HTTP والبروتوكولات الأخرى أيضًا (فقط لذكر أن بروتوكول SOAP يمكن أن يكون البروتوكول الأساسي لـ REST). سأتحدث فقط عن بروتوكول HTTP الخاص بـ SOAP و REST ، لأن هذا هو الاستخدام الأكثر استخدامًا لهما.

صابون

SOAP (بروتوكول الوصول إلى الكائنات "البسيط") هو بروتوكول ( ومعيار W3C ). يحدد كيفية إنشاء رسائل SOAP وإرسالها ومعالجتها.

  • رسائل SOAP هي مستندات XML ذات بنية محددة: تحتوي على مغلف يحتوي على الرأس وقسم النص الأساسي. يحتوي الجسم على البيانات الفعلية - نريد إرسالها - بتنسيق XML. هناك نوعان من أنماط التشفير ، لكننا عادة ما نختار الحرف ، وهذا يعني أن التطبيق لدينا أو برنامج التشغيل SOAP الخاص به يقوم بتسلسل XML وعدم إلغاء تسلسل البيانات.

  • تسافر رسائل SOAP كرسائل HTTP مع النوع الفرعي لـ SOAP + XML MIME. يمكن أن تكون رسائل HTTP هذه متعددة الأجزاء ، لذا يمكنك اختياريًا إرفاق الملفات برسائل SOAP.

  • من الواضح أننا نستخدم بنية خادم العميل ، لذا يرسل عملاء SOAP الطلبات إلى مواقع ويب SOAP وترسل الخدمات الردود إلى العملاء. تستخدم معظم خدمات الويب ملف WSDL لوصف الخدمة. يحتوي ملف WSDL على XML Schema (XSD) للبيانات التي نريد إرسالها وربط WSDL الذي يحدد كيفية ارتباط خدمة الويب ببروتوكول HTTP. هناك نوعان من أساليب الربط : RPC والمستند. من خلال نمط RPC الربط ، يحتوي جسم SOAP على تمثيل لمكالمة تشغيل مع المعلمات (طلبات HTTP) أو قيم الإرجاع (استجابة HTTP). يتم التحقق من صحة المعلمات وقيم الإرجاع مقابل XSD. من خلال ربط نمط الوثيقة ، يحتوي نص SOAP على وثيقة XML يتم التحقق منها مقابل XSD. أعتقد أن نمط تجليد الوثيقة يناسب بشكل أفضل الأنظمة القائمة على الأحداث ، لكني لم أستخدم هذا النمط الملزم. نمط ربط RPC أكثر انتشارًا ، لذلك يستخدم معظم الأشخاص SOAP لأغراض XML / RPC من خلال التطبيقات الموزعة. عادة ما تجد خدمات الويب بعضها البعض عن طريق طلب خادم UDDI . خوادم UDDI هي السجلات التي تخزن موقع خدمات الويب.

SOAP RPC

لذا - في رأيي - تستخدم معظم خدمات الويب SOAP الشائعة أسلوب ربط RPC ونمط التشفير الحرفي ولها الخصائص التالية:

  • انها خرائط عناوين المواقع للعمليات.
  • يرسل رسائل مع نوع فرعي SOAP + XML MIME.
  • يمكن أن يكون مخزن جلسة جانب الخادم ، لا توجد قيود حول ذلك.
  • تستخدم برامج تشغيل العميل SOAP ملف WSDL الخدمة لتحويل عمليات RPC إلى أساليب. يتواصل تطبيق جانب العميل مع خدمة الويب SOAP عن طريق استدعاء هذه الطرق. لذا فإن معظم عملاء SOAP يكسرون تغييرات الواجهة (أسماء الأسلوب الناتجة و / أو تغييرات المعلمات).
  • من الممكن كتابة عملاء SOAP الذين لن يكسروا تغيرات الواجهة باستخدام RDF وإيجاد العمليات عن طريق الدلالات ، لكن خدمة الويب الدلالية هي نادرة جدا وليس بالضرورة أن يكون لها عميل غير خارق (أظن).

راحة

REST (نقل الحالة التمثيلي) هو نمط هندسي موصوف في dissertation Roy Fielding. لا يهم حول البروتوكولات مثل SOAP. يبدأ بنمط هندسة فارغة بدون قيود ويعرف قيود هندسة REST واحدة تلو الأخرى. يستخدم الأشخاص مصطلح RESTful for webservices التي تفي بجميع قيود REST ، ولكن وفقًا لـ Roy Fielding ، لا توجد أشياء مثل مستويات REST . عندما لا تتلاقى خدمة الويب مع كل قيد REST واحد ، فهي ليست خدمة ويب REST.

قيود REST

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

    • تحديد الموارد - موارد REST هي نفسها مورد RDF . وفقًا لـ Fielding إذا كان بإمكانك تسمية شيء ما ، فيمكن أن يكون موردًا ، على سبيل المثال: "الطقس المحلي الحالي" يمكن أن يكون موردًا ، أو "يمكن أن يكون هاتفك المحمول موردًا ، أو" يمكن أن يكون "مستند ويب محدد" مورد. لتحديد مورد ، يمكنك استخدام مُعرّفات الموارد: عناوين URL و URN (على سبيل المثال ، رقم ISBN بواسطة الكتب ). يجب أن يكون المعرف الوحيد مقتصراً على مورد معين فقط ، ولكن يمكن لمورد واحد أن يحتوي على العديد من المعرفات ، والتي نستغلها على سبيل المثال عن طريق ترقيم الصفحات باستخدام عناوين URL مثل https://example.com/api/v1/users?offset=50&count=25 . تحتوي عناوين URL على بعض specifications ، على سبيل المثال عناوين URL ذات المسارات نفسها لكن طلبات البحث المختلفة غير متطابقة ، أو يجب أن يحتوي جزء المسار على البيانات الهرمية لعنوان URL ويجب أن يحتوي جزء الاستعلام على البيانات غير الهرمية. هذه هي أساسيات كيفية إنشاء عناوين URL بواسطة REST. راجع للشغل. لا يهم بنية عنوان URL إلا لمطوري الخدمة ، ولا يهتم عميل REST الحقيقي به. سؤال آخر يتكرر طرحه هو إصدار API ، وهو أمر سهل ، لأنه وفقا لـ Fielding فإن ​​الشيء الثابت الوحيد حسب الموارد هو الدلالات. إذا تغيرت الدلالات ، يمكنك إضافة رقم إصدار جديد. يمكنك استخدام الإصدار رقم 3 الكلاسيكي وإضافة الرقم الرئيسي فقط إلى عناوين URL ( https://example.com/api/v1/ ). لذلك من خلال التغييرات المتوافقة للخلف ، لا يحدث شيء ، من خلال تغييرات متوافقة غير متخلفة ، سيكون لديك دلالات غير متوافقة مع السابقة مع جذر API API جديد https://example.com/api/v2/ . لذا لن ينكسر العملاء القدامى ، لأنهم يمكنهم استخدام https://example.com/api/v1/ مع الدلالات القديمة.
    • التلاعب بالموارد من خلال التمثيلات - يمكنك التعامل مع البيانات المتعلقة بالموارد (حالة الموارد) عن طريق إرسال التمثيل المقصود للموارد - بالإضافة إلى طريقة HTTP ومعرف الموارد - إلى خدمة REST. على سبيل المثال ، إذا كنت ترغب في إعادة تسمية مستخدم بعد الزواج ، فيمكنك إرسال طلب PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} حيث {name: "Mrs Smith"} هو تمثيل JSON لحالة المورد المقصودة ، وبعبارة أخرى: الاسم الجديد. ويحدث هذا الأمر على هيئة Vica-versa ، حيث ترسل الخدمة تمثيلات للموارد إلى العملاء من أجل تغيير حالاتهم. على سبيل المثال ، إذا أردنا قراءة الاسم الجديد ، فيمكننا إرسال طلب استرداد GET https://example.com/api/v1/users/1?fields="name" ، مما يؤدي إلى الحصول على 200 ok, {name: "Mrs Smith"} . حتى نتمكن من استخدام هذا التمثيل لتغيير حالة العميل ، على سبيل المثال يمكننا عرض "مرحبا بك في صفحتنا السيدة سميث!" رسالة. يمكن أن يحتوي المورد على العديد من التمثيلات اعتمادًا على معرف المورد (URL) أو رأس المقبولة الذي أرسلناه مع الطلب. على سبيل المثال ، يمكننا إرسال صورة السيدة سميث (ربما لا تكون عارية) في حالة طلب image/jpeg .
    • رسائل وصفية ذاتية - يجب أن تحتوي الرسائل على معلومات حول كيفية معالجتها. على سبيل المثال ، طريقة URI و HTTP ، رأس نوع المحتوى ، رؤوس ذاكرة التخزين المؤقت ، RDF الذي يصف معنى البيانات ، إلخ ... من المهم استخدام الطرق القياسية. من المهم معرفة specification أساليب HTTP. على سبيل المثال ، يعني GET استرداد المعلومات التي تم تحديدها بواسطة عنوان URL للطلب ، يعني DELETE مطالبة الخادم بحذف المورد المحدد بواسطة عنوان URL المعين ، وهكذا ... تحتوي رموز حالة HTTP على specification أيضًا ، على سبيل المثال 200 تعني النجاح ، 201 تعني تم إنشاء مورد جديد ، يعني 404 أنه لم يتم العثور على المورد المطلوب على الخادم ، إلخ ... استخدام المعايير الحالية جزء مهم من REST.
    • Hypermedia كمحرك لحالة التطبيق (HATEOAS) - Hypermedia هو نوع وسائط يمكن أن يحتوي على ارتباطات تشعبية. عبر الويب ، نتبع الروابط - التي تم وصفها بتنسيق hypermedia (عادةً HTML) - لتحقيق هدف ، بدلاً من كتابة عناوين URL في شريط الأدوات. يتبع REST نفس المفهوم ، يمكن أن تحتوي التوضيحات المرسلة بواسطة الخدمة على ارتباطات تشعبية. نستخدم هذه الارتباطات التشعبية لإرسال الطلبات إلى الخدمة. مع الاستجابة نحصل على البيانات (وربما المزيد من الروابط) التي يمكننا استخدامها لبناء حالة العميل الجديدة ، وهكذا ... لذلك السبب هو hypermedia هو محرك حالة التطبيق (حالة العميل). ربما تتساءل كيف يتعرف العملاء على الارتباطات التشعبية ويتبعونها؟ من جانب البشر ، الأمر بسيط جدًا ، حيث نقرأ عنوان الرابط ، وربما نملأ حقول الإدخال ، وبعد ذلك نقرة واحدة فقط. من خلال الآلات ، يجب إضافة دلالات إلى الارتباطات مع RDF (بواسطة JSON-LD مع Hydra ) أو مع حلول خاصة بالوسائط الفائقة (على سبيل المثال ، ارتباطات IANA وأنواع MIME الخاصة بالمورد بواسطة HAL+JSON ). هناك العديد من تنسيقات XML و JSON hypermedia الجهاز ، فقط قائمة قصيرة منها:

      في بعض الأحيان يكون من الصعب اختيار ...

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

REST webservice - اختلافات webservice SOAP RPC

لذا فإن خدمة الويب REST مختلفة تمامًا عن خدمة الويب SOAP (مع نمط ربط RPC ونمط التشفير الحرفي)

  • يحدد واجهة موحدة (intead لبروتوكول).
  • يقوم بتعيين عناوين URL إلى الموارد (وليس العمليات).
  • يرسل رسائل مع أي أنواع MIME (بدلاً من فقط SOAP + XML).
  • لديه اتصال عديم الجنسية ، ولذلك لا يمكن أن يكون لديك تخزين على جانب الخادم. (SOAP لا يوجد قيد حول هذا)
  • وهو يعمل على الوسائط الفائقة ويستخدم العملاء الروابط التي يحتوي عليها هذا الجهاز الفائق لطلب الخدمة. (يستخدم بروتوكول SOAP RPC عمليات الربط الموضحة في ملف WSDL)
  • لا يتم تقسيمه عن طريق تغيير عنوان URL فقط من خلال تغييرات دلالات الألفاظ. (عملاء SOAP RPC دون استخدام دلالات RDF فاصل بواسطة تغييرات ملف WSDL.)
  • وهو يتسع بشكل أفضل من خدمة ويب SOAP بسبب سلوكه عديم الجنسية.

وما إلى ذلك وهلم جرا...

لا تلبي خدمة ويب SOAP RPC كل قيود REST:

  • هندسة العميل الخادم - دائما
  • عديم الجنسية - possible
  • مخبأ - possible
  • واجهة موحدة - أبدا
  • نظام الطبقات - possible
  • كود عند الطلب (اختياري) - ممكن

SOAP - بروتوكول الوصول إلى الكائنات البسيط هو بروتوكول !

REST - نقل الدولة التمثيلية هو أسلوب معماري !

SOAP هو بروتوكول XML يستخدم لنقل الرسائل ، عادة عبر HTTP

لا يمكن القول إن REST و SOAP لا يستبعد أحدهما الآخر. قد تستخدم بنية RESTful HTTP أو SOAP أو بروتوكول اتصال آخر. تم تحسين REST للويب وبالتالي HTTP هو الخيار الأمثل. HTTP هو أيضًا البروتوكول الوحيد الذي تمت مناقشته في ورقة Roy Fielding.

على الرغم من اختلاف REST و SOAP بشكل كبير ، إلا أن السؤال يضيء حقيقة أن REST و HTTP غالباً ما يتم استخدامهما بالترادف. ويرجع ذلك في المقام الأول إلى بساطة بروتوكول HTTP وتخطيطه الطبيعي جدًا لمبادئ RESTful.

أساسيات REST الأساسية

اتصال العميل الخادم

تتميز معماريات العميل والخادم بفصل مميز للغاية عن المخاوف. جميع التطبيقات التي بنيت في نمط RESTful يجب أن تكون أيضا خادم العميل في princple.

عديم الجنسية

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

القابلة للتخزين المؤقت

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

واجهة موحدة

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

تمثل المفاهيم المذكورة أعلاه تحديد خصائص REST وتمييز بنية REST من البنى الأخرى مثل خدمات الويب. من المفيد ملاحظة أن خدمة REST هي خدمة ويب ، ولكن خدمة الويب ليست بالضرورة خدمة REST.

انظر هذا بلوق post على REST Design Principals لمزيد من التفاصيل عن REST والرصاصات المذكورة أعلاه.


راحة

أنا أفهم أن الفكرة الرئيسية لـ REST بسيطة للغاية. لقد استخدمنا متصفحات الويب لسنوات ورأينا كيف أن مواقع الويب سهلة ومرنة وأداء ، إلخ. تستخدم مواقع HTML الارتباطات التشعبية والنماذج كوسيلة أساسية لتفاعل المستخدم. هدفهم الرئيسي هو السماح لنا ، العملاء ، لمعرفة فقط تلك الروابط التي يمكننا استخدامها في الحالة الراهنة . ويقول REST ببساطة "لماذا لا نستخدم نفس المبادئ لقيادة الكمبيوتر بدلاً من العملاء من خلال تطبيقنا؟" ادمج هذا مع قوة البنية التحتية WWW وستحصل على أداة قاتلة لبناء تطبيقات كبيرة موزعة.

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

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

للأسف ، من الصعب العثور على معلومات صحيحة على REST على الويب ، باستثناء ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm . (وهو الشخص الذي اشتقت REST). أود أن أوصي كتاب "REST في الممارسة" لأنه يعطي تعليمي شامل خطوة بخطوة حول كيفية تتطور من SOAP إلى REST.

صابون

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

مقارنة

لا يهم التفاصيل مثل بروتوكولات النقل وتنسيقات الرسائل و xsd و wsdl وغير ذلك عند مقارنة أي نموذج من RPC إلى REST. والفرق الرئيسي هو أن خدمة RPC تقوم بإعادة اختراع الدراجة من خلال تصميم بروتوكول التطبيق الخاص بها في واجهة برمجة تطبيقات RPC مع الدلالات التي لا تعرفها إلا. لذلك ، يجب على جميع العملاء فهم هذا البروتوكول قبل استخدام الخدمة ، ولا يمكن إنشاء بنية تحتية عامة مثل ذاكرة التخزين المؤقت بسبب دلالات الملكية الخاصة بكافة الطلبات. علاوة على ذلك ، لا تقترح واجهات برمجة التطبيقات (RPC) الإجراءات المسموح بها في الحالة الحالية ، ويجب اشتقاقها من وثائق إضافية. يستلزم REST من ناحية أخرى استخدام واجهات موحدة للسماح للعديد من العملاء لفهم بعض دلالات API ، وفوق ضوابط الوسائط (وصلات) لتسليط الضوء على الخيارات المتاحة في كل حالة. وبالتالي ، فإنه يسمح بالتخزين المؤقت للاستجابات لتوسيع نطاق الخدمات وجعل استخدام API الصحيح قابلاً للاكتشاف بسهولة بدون وثائق إضافية.

بطريقة ما ، فإن SOAP (مثل أي RPC آخر) هو محاولة نفق عبر حدود خدمة تعامل الوسائط المتصلة على أنها صندوق أسود قادر على نقل الرسائل فقط. REST هو قرار الاعتراف بأن الويب هو نظام معلومات موزعة ضخم ، لقبول العالم كما هو ، وتعلم إتقانه بدلاً من القتال ضده.

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

تحديث

أظهرت تجربتي بشكل غير متوقع أن تطوير REST أصعب من SOAP. على الأقل ل. NET. في حين أن هناك أطر عمل كبيرة مثل ASP.NET Web API ، فلا توجد أدوات يمكنها إنشاء بروكسي من جانب العميل تلقائيًا. لا شيء مثل "إضافة مرجع خدمة ويب" أو "إضافة مرجع خدمة WCF". يتعين على المرء كتابة كل شفرة الاستعلام عن التسلسل والخدمة عن طريق اليد. والرجل ، هذا كثير من كود النمطي. أعتقد أن تطوير REST يحتاج إلى شيء يشبه WSDL وتنفيذ الأدوات لكل منصة تطوير. في الواقع ، يبدو أن هناك أرضية جيدة: WADL أو WSDL 2.0 ، لكن لا يبدو أن أيًا من المعايير مدعوم بشكل جيد.

تحديث (يناير 2016)

تبين أن هناك الآن مجموعة واسعة من الأدوات لتعريف API REST. RAML الشخصي هو حاليا RAML .

كيف تعمل خدمات الويب

حسنا ، هذا سؤال واسع جدا ، لأنه يعتمد على الهندسة المعمارية والتكنولوجيا المستخدمة في خدمة ويب محددة. ولكن بشكل عام ، فإن خدمة الويب هي ببساطة بعض التطبيقات في الويب التي يمكنها قبول الطلبات من العملاء وإرجاع الردود. انها تتعرض للويب ، وبالتالي فهي خدمة ويب ، وهي متوفرة عادة 24/7 ، وهذا هو السبب في أنها خدمة . وبطبيعة الحال ، فإنه يحل بعض المشاكل (وإلا لماذا يستخدم أي شخص خدمة ويب) لعملائه.







soap