Почему предпочитаете REST, а не SOAP? - PullRequest
11 голосов
/ 24 ноября 2010

Если мне нужен веб-сервис для передачи сложного объекта туда-сюда, есть ли причина, по которой я предпочитаю SOAP, а не REST?Вот пример возможного сообщения SOAP:

<soap:Envelope>
  <soap:Header>
    <Credentials>
      <User>Joe</User>
      <Password>abc123</Password>
    </Credentials>
  </soap:Header>
  <soap:Body>
    <MyComplexBusinessObject>
      <Search>
        <First>Joe</First>
        <Last>Smith</Last>
      </Search>
      ...
      ...
    </MyComplexBusinessObject>
  </soap:Body>
</soap:Envelope>

Используя REST, я бы попросил клиента отправить POST следующий xml и аутентифицироваться с помощью обычной аутентификации:

<MyComplexBusinessObject>
  <Search>
    <First>Joe</First>
    <Last>Smith</Last>
  </Search>
  ...
  ...
</MyComplexBusinessObject>

SOAPСообщение немного сложнее, но не намного.Они по-прежнему являются XML, но SOAP поставляется с WSDL, и большинство сред программирования будут создавать прокси-классы для вас.Тем не менее, большинство людей, с которыми я общаюсь, говорят, что вместо этого я должен использовать REST, потому что это проще в использовании.Но я не понимаю, как SOAP сложнее в использовании.

Я что-то упустил?

Ответы [ 4 ]

9 голосов
/ 24 ноября 2010

Ваше первое требование "передачи туда и обратно сложного объекта" ограничивает вашу архитектуру, устраняя многие из преимуществ REST.SOAP предназначен для доступа к удаленным объектам, а REST - нет.REST поддерживает передачу типов мультимедиа так же просто, как text / plain, что гораздо более примитивно, чем работа с объектом.

Если вы еще этого не видели, этот вопрос и ответы на негоохватывает большинство проблем REST и SOAP.

5 голосов
/ 24 ноября 2010

Одним из основных преимуществ REST является то, что все, что вам нужно для вызова и использования, - это браузер и стек HTTP - почти в каждом устройстве и машине это есть.Поэтому, если ваша основная цель - простота использования и охват - используйте REST.

Одним из основных преимуществ SOAP является то, что у вас есть описание службы WSDL, и вы в значительной степени можете обнаружить службу автоматически и сгенерировать полезнуюклиентский прокси из этого описания сервиса (генерировать вызовы сервиса, необходимые типы данных для методов и т. д.).

Поэтому, если для вас важнее обнаружение и строгое формальное описание сервиса, используйте SOAP (снедостаток в том, что вам нужен полноценный SOAP-клиент для вызова вашей службы - вашего веб-браузера будет недостаточно).

SOAP не сложнее в использовании - но он просто не настолько «распространен» вусловия доступности - любой браузер может позвонить в службу REST и получить ответ, но тогда ему необходимо проанализировать и интерпретировать этот ответ.SOAP получает хорошую структуру данных, но для этого вам нужен клиент SOAP.

1 голос
/ 20 апреля 2015

Если вы разрабатываете и сервис, и клиент, использовать SOAP так же просто, как и REST (на самом деле проще).

Вы можете предпочесть SOAP, а не REST, если эти условия соответствуют:

  • Весь API службы сложен, а не только один объект.

  • Служба используется в относительно небольшой сети, и производительность не является важным требованием.

  • Вы решаете потратить минимальное количество времени на разработку как службы, так и документации API.

1 голос
/ 11 апреля 2013

Я рассматриваю SOAP и REST как ортогональные API, предназначенные для разных целей.

SOAP - это в основном модный RPC, поэтому, если вы хотите отправить запрос на вычисление на сервер и получить результат обратно,Вы используете SOAP.Если он будет локальным, это будет вызов метода для экземпляра объекта.

REST - это способ создания, извлечения, обновления и удаления удаленных объектов, не в смысле POO, с использованием единого API.Если он будет локальным, это будет похоже на работу с файлом.

Таким образом, они фактически отвечают различным потребностям.Вы можете убить одного, чтобы выполнять работу другого, но вы искажаете значения.

...