web-services - شرح - wsdl




SOAP مقابل REST(الاختلافات) (8)

IMHO لا يمكنك مقارنة SOAP و REST حيث أن هذين شيئين مختلفين.

SOAP هو بروتوكول و REST هو نمط معماري برنامج. هناك الكثير من الاعتقادات الخاطئة في الإنترنت لـ SOAP vs REST .

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

تمثل REST الحالة (كموارد) لملقم من URL.It عديم الجنسية ، ويجب ألا يكون لدى العملاء معرفة مسبقة للتفاعل مع الملقم تفوق فهم hypermedia.

لقد قرأت مقالات حول الاختلافات بين SOAP و REST كبروتوكول اتصالات خدمة ويب ، ولكن أعتقد أن أكبر مزايا REST عبر SOAP هي:

  1. REST أكثر ديناميكية ، لا حاجة لإنشاء وتحديث UDDI.

  2. لا يقتصر REST على تنسيق XML. يمكن لخدمات الويب REST إرسال نص عادي ، JSON ، وكذلك XML.

لكن SOAP أكثر توحيدًا (سابقًا ؛ أمن).

لذا ، هل يمكنني تصحيح هذه النقاط؟


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

ما هو الحمولة؟

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

الآن ، على سبيل المثال ، لا بد لي من إرسال برقية ونعلم جميعا أن تكلفة البرقية تعتمد على بعض الكلمات.

لذا أخبرني فيما بين هاتين الرسالتين ، أيهما أرخص لإرساله؟

<name>Arin</name>

أو

"name": "Arin"

أعلم أن إجابتك ستكون الثانية ، على الرغم من أن كلاهما يمثل نفس الرسالة والثاني أرخص في التكلفة.

لذا أحاول أن أقول إن إرسال البيانات عبر الشبكة بتنسيق JSON أرخص من إرساله بتنسيق XML بخصوص الحمولة .

هنا هي الفائدة الأولى أو مزايا REST على SOAP . يدعم SOAP XML فقط ، ولكن REST يدعم تنسيقًا مختلفًا مثل النص ، JSON ، XML ، وما إلى ذلك. ونحن نعلم بالفعل ، إذا استخدمنا Json ، فمن المؤكد أننا سنكون في مكان أفضل بخصوص الحمولة.

الآن ، يدعم SOAP XML فقط ، ولكن له أيضًا مميزاته.

هل حقا! ماذا؟

يعتمد SOAP على XML في ثلاثة طرق مغلف - يحدد ما هو موجود في الرسالة وكيفية معالجته.

مجموعة من قواعد الترميز لأنواع البيانات ، وأخيرا تخطيط استدعاءات الإجراء والاستجابات التي تم جمعها.

يتم إرسال هذا المغلف عبر النقل (HTTP / HTTPS) ، ويتم تنفيذ RPC (استدعاء الإجراء البعيد) ، ويتم إرجاع المغلف مع معلومات في مستند بتنسيق XML.

النقطة المهمة هي أن إحدى مزايا SOAP هي استخدام النقل "العام" ولكن REST تستخدم HTTP / HTTPS . يمكن استخدام SOAP تقريباً أي النقل لإرسال الطلب ولكن لا يمكن REST. حتى هنا حصلنا على ميزة استخدام SOAP.

كما أشرت سابقا في الفقرة أعلاه "REST يستخدم HTTP / HTTPS" ، لذلك انتقل أعمق قليلا على هذه الكلمات.

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

لكن SOAP يدعم SSL تمامًا مثل REST بالإضافة إلى أنه يدعم أيضًا WS-Security الذي يضيف بعض ميزات أمان المؤسسة. توفر WS-Security الحماية من إنشاء الرسالة إلى استهلاكها . لذا بالنسبة لأمان مستوى النقل ، مهما كانت ثغرة وجدنا أنه يمكن منعها باستخدام WS-Security.

بصرف النظر عن ذلك ، نظرًا لأن REST مقيدة ببروتوكول HTTP ، فإن دعم المعاملة ليس متوافقًا مع ACID ولا يمكنه توفير التزام مرحلتين عبر الموارد عبر الوطنية الموزعة.

لكن SOAP لديها دعم شامل لكل من إدارة معاملات ACID على أساس معاملات قصيرة الأجل وإدارة معاملات قائمة على التعويضات للمعاملات طويلة الأجل. كما يدعم التزام مرحلتين عبر الموارد الموزعة .

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

هنا هو "Java EE 6 Tutorial" حيث قالوا أن تصميم RESTful قد يكون مناسبًا عند استيفاء الشروط التالية . الق نظرة.

آمل أن تستمتع بقراءة إجابتي.


إضافة ل:

++ خطأ غالبًا ما يحدث عند الاقتراب من REST هو اعتباره "خدمات ويب مع عناوين URL" - للتفكير في REST كآلية استدعاء (RPC) إجراء بعيد آخر ، مثل SOAP ، ولكن يتم استدعاؤه من خلال عناوين URL بتنسيق HTTP العادي ودون الحاجة إلى SOAP مساحات أسماء XML.

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


الفرق بين الراحة والصابون

صابون

  1. SOAP هو بروتوكول.
  2. SOAP لتقف على بروتوكول الوصول إلى كائن بسيط.
  3. يتعذر على SOAP استخدام REST نظرًا لأنه بروتوكول.
  4. يستخدم SOAP واجهات الخدمات لفضح منطق الأعمال.
  5. يحدد SOAP المعايير الواجب اتباعها بدقة.
  6. يتطلب SOAP مزيدًا من النطاق الترددي والموارد أكثر من REST.
  7. يحدد SOAP أمانه الخاص.
  8. يسمح SOAP بتنسيق بيانات XML فقط.
  9. SOAP أقل تفضيلاً من REST.

راحة

  1. REST هو أسلوب معماري.
  2. REST لتقف على نقل الدولة تمثيلي.
  3. يمكن أن يستخدم REST خدمات ويب SOAP لأنه مفهوم ويمكنه استخدام أي بروتوكول مثل HTTP ، SOAP.
  4. يستخدم REST URI لعرض منطق الأعمال.
  5. لا يحدد REST الكثير من المعايير مثل SOAP.
  6. يتطلب REST نطاقًا تردديًا أقل وموارد أقل من SOAP.
  7. ترث RESTful خدمات الويب إجراءات الأمان من النقل الأساسي.
  8. تسمح REST بتنسيق بيانات مختلف مثل النص العادي ، HTML ، XML ، JSON إلخ.
  9. بقية يفضل من SOAP.

لمزيد من التفاصيل يرجى الاطلاع here


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

أساسيات REST

  • يعتبر كل شيء في REST كمورد.
  • يتم تحديد كل مورد من خلال URI.
  • يستخدم واجهات موحدة. يتم التعامل مع الموارد باستخدام عمليات POST و GET و PUT و DELETE التي تشبه عمليات الإنشاء والقراءة والتحديث والحذف (CRUD).
  • كن عديم الجنسية. كل طلب هو طلب مستقل. يجب أن يحتوي كل طلب من العميل على الخادم على جميع المعلومات اللازمة لفهم الطلب.
  • الاتصالات تتم عن طريق التمثيل. على سبيل المثال ، XML ، JSON RESTful Web Services. تستند خدمات الويب RESTful على أساليب HTTP ومفهوم REST. تقوم خدمة RESTful على الويب عادة بتعريف URI الأساسي للخدمات ؛ أنواع MIME المدعمة (XML ، النص ، JSON ، المعرفة من قبل المستخدم ، ...) ومجموعة العمليات (POST ، GET ، PUT ، DELETE) التي يتم دعمها.

أساسيات SOAP

  • تحدد WSDL العقد بين العميل والخدمة وهي ثابتة بطبيعتها.
  • ينشئ SOAP بروتوكولًا يستند إلى XML أعلى HTTP أو أحيانًا TCP / IP.
  • SOAP يصف وظائف وأنواع البيانات.
  • SOAP هو خليفة لـ XML-RPC وهو مشابه جدًا ، ولكنه يصف طريقة قياسية للتواصل.
  • العديد من لغات البرمجة لديها دعم أصلي لـ SOAP ، وعادة ما تقوم بإطعامه عنوان URL لخدمة الويب ، ويمكنك استدعاء وظائف خدمات الويب الخاصة بها دون الحاجة إلى رمز معين.
  • يجب ترميز البيانات الثنائية التي يتم إرسالها أولاً إلى تنسيق مثل base64 encoded.
  • لديها العديد من البروتوكولات والتقنيات المتعلقة بها: WSDL ، XSD ، SOAP ، WS-Addressing.

SOAP مقابل REST؟

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

مع خدمات RESTful ، يتم توفير أمان الرسائل بواسطة بروتوكول النقل (HTTPS) وهو من نقطة إلى نقطة فقط. ليس لديها نظام مراسلة قياسي وتتوقع من العملاء التعامل مع حالات فشل الاتصال عن طريق إعادة المحاولة. لدى SOAP منطقًا ناجحًا / مُحَوَّلًا مدمجًا ويوفر موثوقية من النهاية إلى النهاية حتى من خلال وسطاء SOAP.

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

خدمات RESTful خفيفة الوزن أيضًا ، أي أنها لا تحتوي على الكثير من علامات XML الإضافية. لاستدعاء RESTful API ، كل ما تحتاجه هو متصفح أو HTTP stack ، إلى حد كبير كل جهاز أو جهاز متصل بشبكة.

مزايا REST

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

مزايا SOAP

  • WS-Security: بينما يدعم SOAP SSL (تمامًا مثل REST) ​​، فإنه يدعم أيضًا WS-Security الذي يضيف بعض ميزات أمان المؤسسة. يدعم الهوية من خلال الوسطاء ، وليس فقط من نقطة إلى نقطة (SSL). كما يوفر تطبيقًا قياسيًا لسلامة البيانات وخصوصية البيانات. لا يعني أن تسميتها "Enterprise" أنها أكثر أمانًا ، فهي ببساطة تدعم بعض الأدوات الأمنية التي لا تحتاجها خدمات الإنترنت المعتادة ، بل هي في الواقع لا تحتاج إلا في عدد قليل من سيناريوهات "المؤسسات".
  • WS-AtomicTransaction: تحتاج إلى معاملات ACID عبر إحدى الخدمات ، فستحتاج إلى SOAP. بينما يدعم REST المعاملات ، إلا أنه ليس شاملاً وغير متوافق مع ACID. لحسن الحظ ، لا تكون معاملات ACID ذات معنى تقريباً على الإنترنت. REST مقيدة بواسطة HTTP نفسها والتي لا يمكنها توفير التزام مرحلتين عبر موارد المعاملات الموزعة ، ولكن يمكن SOAP. لا تحتاج تطبيقات الإنترنت إلى هذا المستوى من الموثوقية في المعاملات ، في حين أن تطبيقات المؤسسة في بعض الأحيان.
  • WS-ReliableMessaging: ليس لدى Rest نظام مراسلة قياسي ويتوقع من العملاء التعامل مع حالات فشل الاتصال عن طريق إعادة المحاولة. لدى SOAP منطقًا ناجحًا / مُحَوَّلًا مدمجًا ويوفر موثوقية من النهاية إلى النهاية حتى من خلال وسطاء SOAP.
  • اللغة والنظام الأساسي والنقل مستقلة (يتطلب REST استخدام HTTP)
  • يعمل بشكل جيد في بيئات المؤسسات الموزعة (REST يفترض الاتصال المباشر من نقطة إلى نقطة)
  • موحدة
  • يوفر تمدد كبير قبل البناء في شكل معايير WS
  • المدمج في معالجة الأخطاء
  • الأتمتة عند استخدامها مع منتجات لغة معينة

أين تستخدم REST

المناطق التي تعمل REST بشكل جيد لها هي:

  • عرض النطاق الترددي والموارد المحدودة: تذكر أن بنية الإرجاع موجودة فعلاً بأي شكل (تم تعريف المطور). بالإضافة إلى ذلك ، يمكن استخدام أي متصفح لأن الأسلوب REST يستخدم أفعال GET و PUT و POST و DELETE القياسية. مرة أخرى ، تذكر أن REST يمكنها أيضًا استخدام كائن XMLHttpRequest الذي تدعمه معظم المتصفحات الحديثة حاليًا ، مما يضيف مكافأة AJAX.
  • عمليات عديمة الحالة: إذا كانت هناك حاجة لاستمرار العملية ، فحينئذٍ لا يكون REST هو المقاربة الأفضل ، وقد يناسبها SOAP بشكل أفضل. ومع ذلك ، إذا كنت بحاجة إلى عمليات CRUD (إنشاء ، قراءة ، تحديث ، وحذف) بدون الحالة ، فحينها تكون REST.
  • حالات التخزين المؤقت: إذا كان من الممكن تخزين المعلومات المخبأة مؤقتًا نظرًا للعملية التي لا تستند إلى الحالة الخاصة بنهج REST ، فهذا أمر مثالي.

أين تستخدم SOAP

المناطق التي يعمل فيها SOAP كحل كبير:

  • المعالجة والتزامن غير المتزامنين: إذا كان التطبيق الخاص بك يحتاج إلى مستوى مضمون من الموثوقية والأمان ، فإن SOAP 1.2 يقدم معايير إضافية لضمان هذا النوع من العمليات. أشياء مثل WSRM - WS-Reliable Messaging.
  • العقود الرسمية: إذا كان على كلا الطرفين (المزود والمستهلك) الاتفاق على نسق التبادل ، فإن SOAP 1.2 يعطي المواصفات الصلبة لهذا النوع من التفاعل.
  • العمليات الحرجة: إذا احتاج التطبيق إلى معلومات سياقية وإدارة حالة محادثة ، فإن SOAP 1.2 لديه مواصفات إضافية في هيكل WS لدعم تلك الأشياء (الأمن ، المعاملات ، التنسيق ، إلخ). مقارنة ، نهج REST سيجعل المطورين بناء هذه السباكة المخصصة.

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

لا يمكن مقارنة SOAP و REST مباشرة ، لأن الأول هو بروتوكول (أو على الأقل يحاول أن يكون) والثاني هو نمط معماري. ربما يكون هذا أحد مصادر الارتباك حوله ، حيث يميل الناس إلى استدعاء REST أي HTTP API غير SOAP.

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

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

أعتقد أن هذه هي النقاط الأساسية لفهم ما يدور حول REST ، وكيف يختلف عن SOAP:

  • REST هو بروتوكول مستقل. لا يقترن إلى HTTP. تشبه إلى حد كبير يمكنك اتباع رابط ftp على موقع ويب ، يمكن استخدام تطبيق REST أي بروتوكول له نظام URI قياسي.

  • لا يعد REST تعيينًا لـ CRUD إلى أساليب HTTP. اقرأ this الإجابة للحصول على شرح مفصل عن ذلك.

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

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

  • REST هو النمط المعماري للشبكة نفسها. عندما تقوم بإدخال ، فأنت تعرف ما هو "المستخدم" و "سؤال وجواب" ، كما تعرف أنواع الوسائط ، ويوفر لك موقع الويب الارتباطات الخاصة بهما. لدى REST API نفس الشيء. إذا صممنا الويب بالطريقة التي يفكر فيها REST ، بدلاً من أن يكون لديك صفحة رئيسية تحتوي على روابط إلى أسئلة وأجوبة ، سيكون لدينا وثائق ثابتة تشرح أنه من أجل عرض سؤال ما ، يجب أن تأخذ URI .com/questions/<id> ، استبدل id بـ Question.id ولصق ذلك في المتصفح. هذا هراء ، ولكن هذا ما يعتقده الكثيرون REST.

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

مع مراعاة ما سبق ، ستدرك أنه على الرغم من أن REST قد لا يقتصر على XML ، فإن القيام بذلك بشكل صحيح مع أي تنسيق آخر سيتعين عليك تصميم وتوحيد بعض التنسيقات لارتباطاتك. الارتباطات التشعبية قياسية في XML ، ولكن ليس في JSON. هناك مسودة لمعايير JSON ، مثل HAL .

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


  • SOAP هو بروتوكول بينما تكون REST بنية.
  • يعرض SOAP السلوك الذي يمثل المنطق بينما يعرض REST الموارد التي تمثل البيانات.
  • من حيث الاستهلاك ، تعتبر خدمة REST أبسط بكثير من SOAP. مع التخلص من النفقات العامة لمعالجة المغلفات XML التي يتم التخلص منها مما يجعلها أسرع بالمقارنة مع SOAP.
  • قدم SOAP خيارات أمان جيدة بالمقارنة مع REST.
  • من أجل التفاعل بين الماكينة والآلة والحلول المؤسسية ، يكون SOAP مفضلاً ، ولكن REST العامة هي أفضل خيار تقريبًا 70٪ من API العام هي REST.
  • REST هي خفيفة الوزن وقابلة للصيانة وقابلة للتطوير.
  • REST هو جهاز مستقل بمعنى أن عميل REST الذي يستهلك REST API يمكن أن يكون أي شيء مثل الأجهزة المحمولة وأجهزة الكمبيوتر المحمولة والتلفزيون وما إلى ذلك.
  • مع السحابة القادمة في العمل. التطبيق يتحرك ببطء إلى الأنظمة القائمة على السحابة مثل Azure و Amazon AWS. هذه الأنظمة هي بناء وتعريض REST API. ومن ثم فهي خطوة جيدة لإنشاء تطبيق في الجزء العلوي من REST API.

REST Vs SOAP


REST مقابل SOAP ليس هو السؤال الصحيح للسؤال.

REST ، على عكس SOAP ليست بروتوكول.

REST هو نمط معماري وتصميم لبنية البرمجيات القائمة على الشبكات.

ويشار إلى مفاهيم REST كموارد. يجب أن يكون تمثيل المورد عديم الحالة. يتم تمثيل عبر بعض أنواع الوسائط. تتضمن بعض أمثلة أنواع الوسائط XML و JSON و RDF . يتم التلاعب الموارد من المكونات. تطلب المكونات وتتعامل مع الموارد عبر واجهة موحدة قياسية. في حالة HTTP ، تتكون هذه الواجهة من عمليات HTTP القياسية مثل GET و PUT و POST و DELETE .

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

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

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

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

عديم الجنسية

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

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

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

واجهة موحدة

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

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

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

تحرير: تحديث المحتوى على أساس التعليقات





soap