Зачем выбирать REST над SOAP?

Если мне нужна веб-служба для передачи назад и вперед сложного объекта, есть ли причина, по которой я должен предпочесть 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 и пройти аутентификацию с помощью Basic Authentication:

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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