Я прочитал несколько уже заданных вопросов о мыле и отдыхе и я не нашел ответ, который я ищу. У нас есть система, которая была построена с использованием веб-сервисов Soap. Система не очень эффективна и обсуждается для замены всех веб-сервисов Soap для веб-служб REST. Кто-то утверждал, что "Отдых" имеет лучшую производительность. Я не знаю, правда ли это. (Это был мой первый вопрос) Предполагая, что это так, есть ли недостаток, REST вместо мыла? (Мы что-то теряем?)
Спасибо заранее.
Производительность - это широкая тема.
Если вы имеете в виду нагрузку на сервер, REST имеет немного лучшую производительность, поскольку он несет минимальные накладные расходы поверх HTTP. Обычно SOAP приносит с собой стек разных (сгенерированных) обработчиков и парсеров. В любом случае, разница в производительности сама по себе не такая большая, но RESTful-сервис легче масштабировать, так как у вас нет сеансов на стороне сервера.
Если вы имеете в виду производительность сети (т.е. пропускную способность), REST имеет гораздо лучшую производительность. По сути, это просто HTTP. Нет накладных расходов. Таким образом, если ваша служба работает поверх HTTP в любом случае, вы не можете получить намного меньше, чем REST. Кроме того, если вы кодируете свои представления в JSON (в отличие от XML), вы сохраните еще много байтов.
Короче говоря, я бы сказал "да", вы будете более результативны с REST. Кроме того, это (на мой взгляд) упростит ваш интерфейс для ваших клиентов. Таким образом, не только ваш сервер становится более компактным, но и клиентом.
Однако, пару вещей, которые нужно учитывать (поскольку вы спросили "что вы потеряете?" ):
Интерфейсы RESTful, как правило, немного более "болтливые", поэтому в зависимости от вашего домена и того, как вы разрабатываете свои ресурсы, вы можете в конечном итоге выполнять больше HTTP-запросов.
SOAP имеет очень широкую поддержку инструмента. Например, консультанты любят это, потому что они могут использовать инструменты для определения интерфейса и генерации файла wsdl, а разработчики любят его, потому что они могут использовать другой набор инструментов для создания всего сетевого кода из этого wsdl файла. Более того, XML как представление имеет схемы и валидаторы, которые в некоторых случаях могут быть ключевой проблемой. (JSON и REST имеют аналогичный материал, но поддержка инструмента далеко позади)
SOAP требует, чтобы XML-сообщение анализировалось, и все, что было отправлено и получено, все это: ltd riduculouslylongnamespace: mylongtagname > extra </riduculouslylongnamespace: mylongtagname > .
REST обычно использует что-то гораздо более тонкое и легко разбирается, как JSON.
Однако на практике разница не такая уж большая.
Построение DOM из XMLis обычно выполняется сверхбыстрое супероптимизированное фрагмент кода, например, XERCES в С++ или Java, тогда как большинство парсеров JSON находятся в ролике вашей собственной или интерпретируемой категории.
В быстрой сетевой среде (ЛВС или широкополосной) нет большой разницы между отправкой одного или двух К по сравнению с 10-15 К.
Вы формулируете вопрос, как будто REST и SOAP каким-то образом взаимозаменяемы в существующей системе. Это не так.
Когда вы используете SOAP (технологию), у вас обычно есть система, определенная в "методах", поскольку в действительности вы имеете дело с RPC.
Когда вы используете REST (архитектурный стиль, а не технологию), вы создаете систему, которая определяется как "ресурсы", а вовсе не в методах. Нет отображения 1:1 между SOAP и REST. Архитектура системы принципиально отличается.
Или вы просто говорите о "RPC через URI", который часто путается с REST?
Я определенно не эксперт, когда дело доходит до SOAP vs REST, но единственная разница в производительности, о которой я знаю, заключается в том, что SOAP имеет много накладных расходов при отправке/получении пакетов, поскольку на нем базируется XML, требуется заголовок SOAP и т.д. REST использует URL + querystring для выполнения запроса и, следовательно, не отправляет много kB по проводу.
Я уверен, что здесь есть другие ppl, которые могут дать вам лучшие и более подробные ответы, но, по крайней мере, я пробовал;)
Просто добавьте немного к ответу.
Байт заголовка Http при запросе этой страницы с помощью веб-браузера Chrome: 761
Байты, необходимые для образца мыльного сообщения в wikipedia article: 299
Мое заключение. Это не размер байтов на проводе, который позволяет REST работать хорошо.
Очень маловероятно, что простое преобразование SOAP-сервиса в REST приведет к значительным преимуществам производительности. Преимущество REST заключается в том, что, если вы будете следовать ограничениям, вы можете воспользоваться механизмами, которые HTTP обеспечивает для создания масштабируемых систем. Кэширование и разбиение являются инструментами в вашем наборе инструментов.
Одна из других ответов, по-видимому, игнорирует поддержку 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 я имею в виду HTTP-службы REST) подходят для служб, требующих высокой пропускной способности и низкой задержки. Для этих типов услуг вы, вероятно, захотите пойти с чем-то вроде Apache Thrift, 0MQ или множеством других бинарных RPC-протоколов.
Все зависит. REST на самом деле не имеет (хорошего) ответа на ситуацию, когда данные запроса могут стать большими. Я чувствую этот момент, если его иногда упускают из виду при раздувании REST.
Представьте себе сервис, который позволяет запрашивать информационные данные для тысяч различных элементов.
Разработчик SOAP определит метод, который позволит вам получать информацию для одного или нескольких элементов, как вам нравится... в одном вызове.
Разработчик REST будет обеспокоен тем, что его URI станет слишком длинным, поэтому он определит метод GET, который будет использовать один элемент в качестве параметра. Затем вам нужно будет вызвать это несколько раз, один раз для каждого элемента, чтобы получить ваши данные. Чисто и легко понять... но.
В этом случае для службы REST потребуется гораздо больше раундов, чтобы выполнить то, что можно сделать с помощью одного вызова в службе SOAP.
Да, я знаю, что есть обходные пути для обработки больших данных запроса в сценарии REST. Например, вы можете упаковать материал в тело вашего запроса. Но тогда вам нужно будет тщательно определить (как на сервере, так и на стороне клиента), как это должно интерпретироваться. В этих ситуациях вы начинаете ощущать боль, что REST на самом деле не является стандартом (например, SOAP), но скорее способ сделать что-то.
В ситуациях, когда обменивается только относительно ограниченный объем данных, REST - очень хороший выбор. В конце дня это большинство случаев использования.
В общем, веб-служба на основе REST является предпочтительной благодаря своей простоте, производительности, масштабируемости и поддержке для нескольких форматов данных. SOAP предпочтительнее, когда услуга требует комплексной поддержки безопасности и надежности транзакций.
Ответ действительно зависит от функциональных и нефункциональных требований. Задавать вопросы, перечисленные ниже, помогут вам выбрать.
REf: 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 проще реализовать, протестировать и поддерживать)
Вам не нужно делать выбор, современные рамки позволяют вам предоставлять данные в этих форматах с минимальными изменениями. Следуйте своим бизнес-требованиям и загрузите тестовую версию конкретной реализации, чтобы понять пропускную способность, нет правильного ответа на этот вопрос без правильного теста нагрузки конкретной системы.