SOAP - это основанная на контракте технология . Все взаимодействие клиент / сервер записывается и кодифицируется в большом документе (WSDL) и должно быть согласовано и соблюдено обеими сторонами для того, чтобы все работало. Если одна из сторон решит добавить функции, другая сторона должна «эволюционировать» вместе с ней. Обе стороны полностью связаны, соединены в бедре, склеены, женаты навсегда.
Типичный подход к расширению ваших служб SOAP заключается в создании новых документов WSDL для новых версий службы, а также при поддержании старых версий. Другой метод заключается в создании нового интерфейса, содержащего новые методы и наследующего от старого. Подход, который вы описываете в # 1, заключается в том, что IMO нарушает правила SOAP, потому что клиент и сервер теперь будут использовать разные контракты, и это работает только потому, что аддитивные изменения (например, новые методы) могут быть подкреплены в большинстве случаев все будет работать. В тот момент, когда кто-то вносит разрушительные изменения, клиентский контракт не будет совпадать с серверным, и игра окончена. Это сложный процесс для управления, поэтому большинство организаций предпочитают создавать совершенно новые WSDL для каждой новой версии API.
REST волшебным образом не устраняет все эти проблемы, но облегчает управление , не заставляя вас объединять «контракт» всей распределенной системы в один артефакт . Вы используете HTTP? Отлично, тогда вы можете использовать все замечательные функции HTTP, которые также используются в Интернете: прокси-серверы, URL-адреса, согласование контента, аутентификацию и т. Д. Вы хотите общаться с использованием кодировки JSON, а также XML? Сбей себя с ног. Это легко сделать в REST в любое время, не затрагивая существующих клиентов. Вы хотите безопасности? Хорошо, начните оспаривать аутентифицированные учетные данные, используя встроенную поддержку HTTP именно для этого. Все эти вещи (HTTP, JSON и т. Д.) Стандартизированы и описаны в разных местах, и именно так и должно быть.
SOAP объединяет протокол передачи, информацию о местоположении, описание полезной нагрузки, выбор кодировки и методы RPC в одном большом документе. Если вы хотите внести какие-либо изменения в этот список, вам нужен новый документ. Хуже того, некоторые из этих вещей не могут быть изменены вообще.
REST разделяет эти вещи так, что куски могут эволюционировать независимо . Ваши URL-адреса (или, если быть более точным, «URI») возвращаются во время выполнения, и при условии, что клиент не начинает их жестко кодировать могут быть изменены без каких-либо изменений, необходимых клиенту. Аддитивные изменения в ваших типах носителей являются тривиальными, если ваша документация ясно дает понять, что в будущем могут появиться новые поля. У вас также есть возможность создания версий ваших типов мультимедиа, что позволяет сосуществовать в вашей системе типов мультимедиа v1 / v2 / v3 ..., и клиент может выбирать (используя заголовки Accept и Content-Type в HTTP), какой они хотят использовать.
Вы когда-нибудь слышали шутку о владельце Porsche, который покупает новую машину каждый раз, когда пепельница наполняется? Это МЫЛО. То, что должно быть тривиальным изменением, требует капитального ремонта. REST дает вам пылесос. Вы не должны использовать это, но это, конечно, дешевле.