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

Поэтому довольно упрощенно пытаться сравнить эти два, это яблоки с апельсинами.

Тем не менее, конверт SOAP (без данных) составляет всего несколько k, поэтому не должно быть заметной разницы в скорости при условии, что вы получаете сериализованный объект как через SOAP, так и через REST.

Я не знаю ответа на вопрос о тестировании, однако то, что я знаю о формате SOAP, - да, у него есть накладные расходы, но эти накладные расходы не увеличиваются на запрос: если у вас есть один элемент, отправленный в веб-службу , у вас есть накладные расходы + создание одного элемента, и если у вас есть 1000 элементов, отправленных в веб-службу, у вас есть накладные расходы + создание 1000 элементов. Накладные расходы возникают, когда XML-запрос форматируется для конкретной операции, но каждый отдельный элемент аргумента в запросе форматируется одинаково.

Если вы придерживаетесь повторяемых коротких пакетов данных (скажем, 500 элементов), скорость должна быть приемлемой.

Основное влияние на скорость SOAP по сравнению с REST не связано со скоростью передачи данных, а с кэшируемостью. REST предлагает использовать семантику Интернета вместо того, чтобы пытаться туннелировать через него через XML, поэтому веб-службы RESTful обычно предназначены для правильного использования заголовков кеша, поэтому они хорошо работают со стандартной инфраструктурой Интернета, такой как прокси-серверы кеширования и даже кеши локального браузера. Кроме того, использование веб-семантики означает, что такие вещи, как ETags и автоматическое сжатие zip-файлов, являются хорошо понятными способами повышения эффективности.

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

Расширяя ответ "pjz".

Если вы получаете много операций SOAP на основе ИНФОРМАЦИИ (get * type of calls), в настоящее время вы не можете их кэшировать. Но если вы реализуете те же операции с помощью REST, есть вероятность, что данные (в зависимости от вашего бизнес-контекста) могут быть кэшированы, как упоминалось выше. Поскольку SOAP использует POST для своих операций, он не может кэшировать информацию на стороне сервера.

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

Что-то вроде JSON было бы более компактным и, возможно, быстрее для сериализации / десериализации, но не используйте его исключительно по этой причине. Делайте то, что кажется вам разумным в данный момент, и измените это, если это проблема.

Все, что обычно использует HTTP (если только не повторно используется соединение поддержки активности HTTP 1.1, чего не делают многие реализации), запускает новое TCP-соединение для каждого запроса; это довольно плохо, особенно по ссылкам с высокой задержкой. HTTPS намного хуже. Если у вас много коротких запросов от одного отправителя к одному получателю, подумайте, как вы можете уменьшить эти накладные расходы.

Использование HTTP для любого типа RPC (будь то SOAP или что-то еще) всегда приведет к этим накладным расходам. Другие протоколы RPC обычно позволяют поддерживать соединение открытым.

SOAP определенно медленнее. Полезные нагрузки значительно больше, и их медленнее собирать, транспортировать, анализировать, проверять и обрабатывать.

По этому поводу было проведено несколько исследований, которые могут оказаться для вас информативными. См. Следующее:

• ИСТОЧНИК: Отдых против производительности мыла
• Вопросы и ответы: SOAP и REST 101
• Обновленные службы данных SQL Server: загрузка Northwind REST и SOAP

Также есть (несколько устаревший) интересный разговор о производительности на эту тему на Форумы MSDN.

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

Думаю, главный вопрос здесь в том, как сравнить RPC с SOAP.

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

Я всегда предпочитаю (JSON-) RPC, потому что

• это легкий
• есть много отличных реализаций для всех языков программирования
• легко учиться / использовать / создавать
• это быстро (особенно с JSON)

хотя есть причины, по которым вы должны использовать SOAP, т.е. если вам нужно именовать параметры, а не полагаться на их правильный порядок

некоторые дополнительные сведения вы получите из этого stackoverflow вопрос