Отдых против мыла.У REST лучшая производительность?

Question

Я прочитал некоторые вопросы, уже опубликованные здесь, относительно мыла и отдыха, и я не нашел ответ, который искал.У нас есть система, которая была построена с использованием веб-сервисов Soap.Система не очень эффективна, и в настоящее время обсуждается замена всех веб-сервисов Soap на веб-сервисы REST.Кто-то утверждал, что у отдыха лучше показатели.Я не знаю, правда ли это.(Это был мой первый вопрос). Предполагая, что это правда, есть ли недостаток в использовании REST вместо Soap?(Мы что-то теряем?)

Заранее спасибо.

Answer 1

Производительность - это широкая тема.

Если вы имеете в виду нагрузку на сервер, производительность REST немного выше, поскольку она требует минимальных накладных расходов поверх HTTP.Обычно SOAP приносит с собой стек различных (сгенерированных) обработчиков и анализаторов.В любом случае, разница в производительности не так велика, но сервис RESTful легче масштабировать, поскольку у вас нет никаких сеансов на стороне сервера.

Если вы имеете в виду производительность сети (то есть пропускную способность),REST имеет гораздо лучшую производительность.По сути, это просто HTTP.Нет накладных расходов.Таким образом, если ваш сервис работает поверх HTTP, вы не можете получить намного меньше, чем REST.Более того, если вы закодируете свои представления в JSON (в отличие от XML), вы сэкономите гораздо больше байтов.

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

Однако нужно учитывать несколько моментов (поскольку вы спросили: «Что вы потеряете?»):

Интерфейсы RESTful, как правило, немного более «болтливы», поэтому в зависимости от вашего доменакак вы проектируете свои ресурсы, вы можете в конечном итоге делать больше HTTP-запросов.

SOAP имеет очень широкую поддержку инструментов.Например, консультантам это нравится, потому что они могут использовать инструменты для определения интерфейса и создания файла wsdl, а разработчики любят его, потому что они могут использовать другой набор инструментов для генерации всего сетевого кода из этого файла wsdl.Более того, XML как представление имеет схемы и валидаторы, что в некоторых случаях может быть ключевым вопросом.(У JSON и REST есть похожие вещи, но поддержка инструментов далеко позади)

Answer 2

SOAP требует, чтобы XML-сообщение было проанализировано и все эти extra </ riduculouslylongnamespace: mylongtagname> вещи были отправлены и получены.

REST обычно использует что-то гораздо более сжатое и легко анализируемое, например, JSON.

Однако на практике разница не так уж велика.

Создание DOM из XML обычно выполняется сверхбыстрым супероптимизированным фрагментом кода, таким как XERCES на C ++ или Java, тогда как большинство анализаторов JSON находятся в стадии разработки, как ваша собственная, так и интерпретируемая категория.

В быстром сетевом окружении (LAN или Broadband) нет большой разницы между отправкой одного или двух K против 10 до 15 k.

Answer 3

Вы формулируете вопрос так, как будто REST и SOAP каким-то образом взаимозаменяемы в существующей системе. Это не так.

Когда вы используете SOAP (технологию), у вас обычно есть система, которая определена в «методах», поскольку в действительности вы имеете дело с RPC.

Когда вы используете REST (архитектурный стиль, а не технология), вы создаете систему, которая определяется в терминах «ресурсов», а не в методах. Между SOAP и REST нет сопоставления 1: 1. Архитектура системы принципиально иная.

Или вы просто говорите о "RPC через URI", который часто путают с REST?

Answer 4

Одна вещь, которую другие ответы, похоже, упускают из виду, это поддержка REST для кэширования и другие преимущества HTTP. Хотя SOAP использует HTTP, он не использует преимущества инфраструктуры поддержки HTTP. Привязка SOAP 1.1 определяет только использование глагола POST. Это было исправлено в версии 1.2 с введением привязок GET, однако это может быть проблемой при использовании более старой версии или при отсутствии соответствующих привязок.

Безопасность - еще одна ключевая проблема производительности. Приложения REST обычно используют TLS или другие механизмы безопасности на уровне сеанса. TLS намного быстрее, чем использование механизмов безопасности на уровне приложений, таких как WS Security (WS Security также страдает от недостатков безопасности ).

Однако я думаю, что это в основном незначительные проблемы при сравнении сервисов на основе SOAP и REST. Вы можете найти обходные пути для проблем производительности SOAP или REST. Мое личное мнение таково, что ни SOAP, ни REST (под REST я имею в виду службы REST на основе HTTP) не подходят для служб, требующих высокой пропускной способности и низкой задержки. Для этих типов сервисов вы, вероятно, захотите использовать что-то вроде Apache Thrift, 0MQ или множество других двоичных протоколов RPC.

Answer 5

Я определенно не эксперт в том, что касается SOAP и REST, но единственное известное мне различие в производительности заключается в том, что SOAP имеет большие издержки при отправке / получении пакетов, поскольку он основан на XML, требует заголовок SOAP и т. Д. .REST использует URL + строку запроса для выполнения запроса и, следовательно, не отправляет столько килобайт по сети.

Я уверен, что здесь, на SO, есть другие люди, которые могут дать вам лучшие и более подробные ответы, но, по крайней мере, я пытался;)

Answer 6

Просто добавьте немного к ответу wuher.

Байты заголовка Http при запросе этой страницы с помощью веб-браузера Chrome: 761
Байт, необходимых для образца сообщения мыла в wikipedia article: 299

Мой вывод: не размер байтов в проводе позволяет REST работать хорошо.

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

Answer 7

Все зависит.REST на самом деле не имеет (хорошего) ответа на ситуацию, когда данные запроса могут стать большими.Я чувствую этот момент, если иногда упускаю из виду при отображении REST.

Давайте представим сервис, который позволяет запрашивать информационные данные для тысяч различных элементов.

Разработчик SOAP определил бы метод, который позволил бывы извлекаете информацию для одного или нескольких элементов, которые вам нравятся ... за один вызов.

Разработчик REST будет обеспокоен тем, что его URI станет слишком длинным, поэтому он определит метод GET, который будет приниматьодин элемент в качестве параметра.Затем вам придется вызывать это несколько раз, один раз для каждого элемента, чтобы получить ваши данные.Чистый и простой для понимания ... но.

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

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

Для ситуаций, когда обменивается только относительно ограниченный объем данных, REST оченьхороший выбор.В конце дня это большинство вариантов использования.

Answer 8

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

Ответ действительно зависит от функциональных и нефункциональных требований. Задавая вопросы, перечисленные ниже, вы сможете выбрать.

REf: http://java -success.blogspot.ca / 2012/02 / java-web-services-интервью-questions.html

Предоставляет ли сервис данные или бизнес-логику? (REST - лучший выбор для предоставления данных, SOAP WS - лучший выбор для логики). Требуют ли потребители и поставщики услуг официального контракта? (SOAP имеет официальный контракт через WSDL) Нужно ли поддерживать несколько форматов данных? Нужно ли совершать AJAX-звонки? (REST может использовать XMLHttpRequest) Является ли вызов синхронным или асинхронным? Вызов с состоянием или без гражданства? (REST подходит для статических операций CRUD) Какой уровень безопасности требуется? (SOAP WS лучше поддерживает безопасность) Какой уровень поддержки транзакций требуется? (SOAP WS лучше поддерживает управление транзакциями) У нас есть ограниченная ширина полосы? (SOAP более многословен) Что лучше для разработчиков, которые будут создавать клиентов для сервиса? (REST проще внедрить, протестировать и поддерживать)

Answer 9

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