Отдых против мыла. У REST лучшая производительность?
Я прочитал некоторые вопросы, уже опубликованные здесь, относительно мыла и отдыха, и я не нашел ответ, который искал. У нас есть система, которая была построена с использованием веб-сервисов Soap. Система не очень эффективна, и в настоящее время обсуждается замена всех веб-сервисов Soap на веб-сервисы REST. Кто-то утверждал, что у Rest лучше показатели. Я не знаю, правда ли это. (Это был мой первый вопрос). Предполагая, что это правда, есть ли недостаток в использовании REST вместо Soap? (Мы что-то теряем?)
Заранее спасибо.
9 ответов
Производительность это широкая тема.
Если вы имеете в виду нагрузку на сервер, REST имеет немного лучшую производительность, поскольку он несет минимальные накладные расходы поверх HTTP. Обычно SOAP приносит с собой стек различных (сгенерированных) обработчиков и парсеров. В любом случае, разница в производительности не так уж велика, но RESTful-сервис легче масштабировать, поскольку у вас нет сеансов на стороне сервера.
Если вы имеете в виду производительность сети (то есть пропускную способность), REST имеет гораздо лучшую производительность. По сути, это просто HTTP. Нет накладных расходов. Таким образом, если ваш сервис работает поверх HTTP, вы не можете получить намного меньше, чем REST. Более того, если вы закодируете свои представления в JSON (в отличие от XML), вы сэкономите гораздо больше байтов.
Короче говоря, я бы сказал "да", вы будете более продуктивными с REST. Кроме того, это (на мой взгляд) облегчит использование вашего интерфейса для ваших клиентов. Таким образом, не только ваш сервер становится стройнее, но и клиент тоже.
Тем не менее, несколько вещей, чтобы рассмотреть (так как вы спросили "что вы потеряете?"):
Интерфейсы RESTful, как правило, немного более "болтливы", поэтому в зависимости от вашего домена и того, как вы проектируете свои ресурсы, вы можете в конечном итоге выполнять больше HTTP-запросов.
SOAP имеет очень широкую поддержку инструментов. Например, консультантам это нравится, потому что они могут использовать инструменты для определения интерфейса и создания файла wsdl, а разработчики любят его, потому что они могут использовать другой набор инструментов для генерации всего сетевого кода из этого файла wsdl. Более того, XML как представление имеет схемы и валидаторы, что в некоторых случаях может быть ключевым вопросом. (У JSON и REST есть похожие вещи, но поддержка инструментов далеко позади)
SOAP требует, чтобы XML-сообщение было проанализировано, и весь этот материал
REST обычно использует что-то гораздо более лаконичное и легко анализируемое, например JSON.
Однако на практике разница не так уж велика.
Создание DOM из XML обычно выполняется сверхбыстрым супероптимизированным фрагментом кода, таким как XERCES на C++ или Java, тогда как большинство анализаторов JSON находятся в вашем собственном или интерпретируемом разделе.
В быстром сетевом окружении (LAN или Broadband) нет большой разницы между отправкой одного или двух K против 10 до 15 k.
Вы формулируете вопрос так, как будто REST и SOAP каким-то образом взаимозаменяемы в существующей системе. Они не.
Когда вы используете SOAP (технологию), у вас обычно есть система, которая определена в "методах", поскольку в действительности вы имеете дело с RPC.
Когда вы используете REST (архитектурный стиль, а не технология), вы создаете систему, которая определяется в терминах "ресурсов", а не в методах. Между SOAP и REST нет сопоставления 1: 1. Архитектура системы принципиально иная.
Или вы просто говорите о "RPC через URI", который часто путают с REST?
Одна вещь, которую другие ответы, похоже, упускают из виду, это поддержка 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.
Я определенно не эксперт, когда дело касается SOAP против REST, но единственное различие в производительности, которое я знаю, заключается в том, что SOAP имеет большие накладные расходы при отправке / получении пакетов, поскольку он основан на XML, требует заголовок SOAP и т. Д. REST использует URL + строка запроса, чтобы сделать запрос, и, следовательно, не отправляет столько КБ по проводам.
Я уверен, что здесь есть другие люди, которые могут дать вам лучшие и более подробные ответы, но, по крайней мере, я пытался;)
Все это зависит. REST на самом деле не имеет (хорошего) ответа на ситуацию, когда данные запроса могут стать большими. Я чувствую эту точку зрения, если иногда упускаю из виду при раскрутке REST.
Давайте представим сервис, который позволяет запрашивать информационные данные для тысяч различных предметов.
Разработчик SOAP определит метод, который позволит вам извлекать информацию для одного или нескольких элементов, как вам нравится... за один вызов.
Разработчик REST будет обеспокоен тем, что его URI станет слишком длинным, поэтому он определит метод GET, который будет принимать один элемент в качестве параметра. Затем вам придется вызывать это несколько раз, один раз для каждого элемента, чтобы получить ваши данные. Чисто и легко понять... но.
В этом случае для службы REST потребуется гораздо больше циклов, чтобы выполнить то, что можно сделать с помощью одного вызова службы SOAP.
Да, я знаю, что есть обходные пути для обработки больших данных запроса в сценарии REST. Например, вы можете упаковать вещи в тело вашего запроса. Но тогда вам придется тщательно определить (как на стороне сервера, так и на стороне клиента), как это следует интерпретировать. В этих ситуациях вы начинаете ощущать боль в том, что REST на самом деле не стандарт (например, SOAP), а скорее способ ведения дел.
Для ситуаций, когда обменивается только относительно ограниченный объем данных, REST является очень хорошим выбором. В конце дня это большинство случаев использования.
Просто чтобы добавить немного к ответу wuher.
Http заголовок байтов при запросе этой страницы с помощью веб-браузера Chrome: 761
Для примера сообщения мыла в статье в википедии: 299 байт
Мой вывод: не размер байтов на проводе позволяет REST работать хорошо.
Крайне маловероятно, что простое преобразование службы SOAP в REST принесет какие-либо существенные преимущества в производительности. Преимущество REST состоит в том, что если вы будете следовать ограничениям, то сможете воспользоваться механизмами, которые HTTP предоставляет для создания масштабируемых систем. Кэширование и разбиение - это инструменты в вашем наборе инструментов.
В целом, веб-сервис на основе 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 проще реализовать, протестировать и поддерживать)
Вам не нужно делать выбор, современные фреймворки позволяют вам предоставлять данные в этих форматах с минимальными изменениями. Следуйте своим бизнес-требованиям и проведите нагрузочное тестирование конкретной реализации, чтобы понять пропускную способность. Без правильного нагрузочного тестирования конкретной системы не может быть правильного ответа на этот вопрос.