Отдых против мыла. У 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 vs REST, но единственная разница в производительности, о которой я знаю, заключается в том, что SOAP имеет много накладных расходов при отправке/получении пакетов, поскольку на нем базируется XML, требуется заголовок SOAP, и т. д. REST использует URL + querystring для запроса, и, таким образом, не отправляет много kB по проводу.

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

Answer 3

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

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

Однако на практике разница не такая уж большая.

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

В быстрой сетевой среде (ЛВС или широкополосной) нет большой разницы между отправкой одного или двух К по сравнению с 10-15 К.

Answer 4

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

ЛОТ: http://java-success.blogspot.ca/2012/02/java-web-services-interview-questions.html

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

Answer 9

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