Я видел, что SOAP - это "Тяжелый вес", а REST - "Легкий вес". По каким параметрам мы говорим, что REST является легким, чем SOAP?
Раньше мы использовали веб-сервисы модели IFW в нашей компании. Но наш менеджмент сказал нам, что мы разработаем все новые API, продвигающиеся в REST. Мы являемся сторонними поставщиками услуг в моей компании.
Как REST лучше всего подходит для нас?
Что означает "легкий вес" в контексте?
Этот вопрос кажется повторением, но не понимает используемые термины.
REST дает вам сеанс меньше окна в систему. Он не отслеживает вас, это вас не волнует. Все, что вы сделали, это отправить запрос, который содержит... надеюсь, что некоторый идентификатор проверяет, что вы можете это сделать. Он может возвращать код состояния HTTP, он может возвращать какое-то тело, но в конечном счете, как только запрос будет завершен, вы забыли.
SOAP тяжелый в смысле, что он описывает "контракт" между удаленной системой и вашим клиентом. Чтобы ваш клиент мог эффективно общаться, он ДОЛЖЕН реализовать свою схему... это скелет SOAP. Он описывает вызовы, которые вы можете сделать, и объекты, которые вы можете ожидать назад.
Причина, по которой SOAP тяжелая, связана с сериализацией. По каждому запросу SOAP вы обычно сериализуете объект java, отправляете его по HTTP и получаете сериализованный ответ, который десериализуется в объект через отражение... это тяжело. Это также означает, что если конечная точка изменит работу, вы должны изменить свой контракт. Вам не нужно делать это с помощью REST.
С помощью SOAP вы запускаете многопоточные проблемы.
Чтобы быстро ответить..
они могут означать, что служба REST является "легкой", потому что вам не нужно выпускать изменения для клиентов. Вы просто вносите изменения в свою логику, сохраняя URLS, и ответ должен оставаться тем же.
С помощью SOAP... если вы добавили новое поле в объект, вам придется заставить клиента реализовать новую схему. SOAP довольно старый.
REST является легким в том смысле, что он и полагается на стандарт HTTP, чтобы он работал. Очень полезно быстро и быстро запустить полезный веб-сервис. Если вам не нужно строгое определение API, это путь. Большинство веб-сервисов относятся к этой категории. Вы можете обновить API, чтобы обновления API не прерывали его для людей, использующих старые версии (при условии, что они указывают версию). REST по существу требует HTTP и является агматическим форматом, поэтому вы можете использовать XML, JSON, HTML и т.д.).
Но SOAP обернет структуру в SOAP-конверт (следует XML-стандарт). Сложность оболочки SOAP основана на использовании версии сообщения и дополнительных протоколов веб-сервисов. SOAP обычно является транспортно-агностическим, то есть вам необязательно использовать HTTP.
Можно указать, что SOAP был разработан для распределенной вычислительной среды, где REST был разработан для среды с точкой-точкой.
Интересно, можно ли сказать, что, хотя SOAP дает больше безопасности, API на основе REST будет проще на ресурсах и более масштабируемым? В качестве примера Twitter, Facebook, Google Drive, Blogger и т.д. Все имеют API на основе REST, которые клиенты могут использовать.
Посмотрите ссылку для сравнения на SOAP и REST.
Обычно REST уменьшает размер и объем полезной нагрузки запроса, сопоставляя семантику запроса с базовым протоколом HTTP. Например, SOAP обычно добавляет конверт (различной сложности), который использует WSDL (контракт) для типов запросов и ответов и сопоставлений услуг. REST будет просто использовать POST, GET и т.д. для URL с некоторыми HTTP-кодированными параметрами и, следовательно, не имеет принудительного контракта.
Есть несколько аспектов легкого веса. SOAP - только XML, в то время как REST позволяет отправлять любую полезную нагрузку, такую как JSON, которая является менее подробной и простой, чем XML. Вообще говоря, для работы с JSON требуется меньше памяти и меньше пропускной способности, чем XML.
На другом уровне, используя SOAP, вы обычно описываете все как службы. Таким образом, вам нужно определить схему/структуру сообщений для каждого глагола и существительного, то есть "CreateOrder". В REST вы используете предопределенные HTTP-методы, такие как POST, и помещаете существительное/ "ресурс" в URI, который использует уже существующие конструкции на уровне HTTP - не изобретать их в XML.
Затем нужно приложить усилия, чтобы адаптироваться к изменениям. Небольшое изменение в SOAP требует переопределения схемы, переопределения версий wsdl и дескрипторов. В остальном, в лучших мирах, существует определенная степень динамического кодирования в API (ссылки на ссылочные ресурсы, между прочим), так что некоторые изменения могут быть реализованы и вступают в силу напрямую.
Вся строгость веса SOAP, конечно, имеет веские основания для существования. Менее вероятно, что две реализации имеют разные интерпретации API, чем в свободно определенном REST API. SOAP также позволяет реализовать код скелета на разных языках на основе WSDL. В некоторых сложных сценариях это практически единственный эффективный способ работы с SOAP. Marshalling и unmarshalling между объектами и сериализованным XML довольно тяжело и добавляет к тяжести SOAP.