Аргументы о простоте решений с использованием XML-RPC или REST легко понять и с трудом спорить.
Я также часто слышал аргументы, что увеличение накладных расходов SOAP может значительно повлиять на используемую полосу пропускания и, возможно, даже на латентность. Я бы хотел увидеть результаты теста, который количественно оценивает воздействие. Кто-нибудь знает хороший источник такой информации?
Есть несколько исследований, которые были сделаны в отношении этого, что вы можете найти информативным. См. Следующее:
Есть также (несколько устаревший) интересный разговор о производительности на тему в Форумы MSDN.
Короче говоря, большинство из этих источников, похоже, согласны с тем, что SOAP и REST примерно одинаковы для данных общего назначения. Однако некоторые результаты указывают на то, что с двоичными данными REST может быть фактически менее результативным. См. Ссылки на форуме, который я связал для получения более подробной информации об этом.
Основное влияние на скорость SOAP и REST не связано с скоростью передачи, но с возможностью кэширования. REST предлагает использовать веб-семантику вместо того, чтобы пытаться туннелировать ее через XML, поэтому веб-службы RESTful, как правило, предназначены для правильного использования заголовков кеша, поэтому они хорошо работают с инфраструктурой веб-стандарта, например, кешированием прокси и даже локальными кешами браузера. Кроме того, использование веб-семантики означает, что такие вещи, как ETags и автоматическое сжатие на молнии, хорошо понимают способы повышения эффективности.
.. и теперь вы говорите, что хотите тесты. Ну, с помощью Google я нашел одного парня, чье тестирование показывает, что REST будет на 4-6 раз быстрее, чем SOAP, а другой paper, который также поддерживает REST.
REST как протокол не определяет какую-либо форму конверта сообщения, тогда как SOAP имеет этот стандарт.
Таким образом, его несколько упростить, чтобы попытаться сравнить их, они являются яблоками для апельсинов.
Тем не менее, SOAP-конверт (за вычетом данных) составляет всего несколько k, поэтому не должно быть заметной разницы в скорости при условии, что вы извлекаете сериализованный объект через SOAP и REST.
SOAP и любой другой протокол, который использует XML, обычно раздувает ваши сообщения совсем немного - это может быть или не быть проблемой в зависимости от контекста.
Что-то вроде JSON было бы более компактным и, возможно, быстрее сериализовать/десериализовать, но не использовать его исключительно по этой причине. Сделайте то, что вы чувствуете, имеет смысл в то время и измените его, если это проблема.
Все, что обычно использует HTTP (если не повторное использование соединения keepalive HTTP 1.1, которое не выполняется многими реализациями) запускает новое TCP-соединение для каждого запроса; это довольно плохо, особенно в отношении ссылок с высокой задержкой. HTTPS намного хуже. Если у вас есть много коротких запросов от одного отправителя к одному получателю, подумайте о том, как вы можете взять это накладные расходы.
Использование HTTP для любого типа RPC (будь то SOAP или что-то еще) всегда будет нести накладные расходы. Другие протоколы RPC обычно позволяют открывать соединение.
Если вы получаете много операций с SOAP (получение * типа вызовов) на основе SOAP, в настоящее время вы не можете их кэшировать. Но если бы вы выполняли эти же операции с помощью REST, существует вероятность того, что данные (в зависимости от вашего бизнес-контекста) могут быть кэшированы, как указано выше. Поскольку SOAP использует POST для своих операций, он не может кэшировать информацию со стороны сервера.
SOAP определенно медленнее. Полезные нагрузки значительно больше, которые медленнее собираются, транспортируются, анализируются, проверяются и обрабатываются.
Я не знаю никакого ответа на вопрос, связанный с бенчмаркингом, однако то, что я знаю о формате SOAP, да, у него есть накладные расходы, но эти накладные расходы не увеличиваются на каждый запрос: если у вас есть один элемент, отправленный на веб-сервис, у вас есть накладные расходы + одна конструкция элемента, и если у вас есть 1000 элементов, отправленных на веб-службу, у вас есть надстройка + 1000 элементов. Накладные расходы возникают, когда XML-запрос отформатирован для конкретной операции, но каждый отдельный элемент аргумента в запросе отформатирован одинаково.
Если вы придерживаетесь повторяющихся коротких всплесков данных (скажем, 500 элементов), скорость должна быть приемлемой.
Я думаю, главный вопрос здесь в том, как сравнивает RPC с SOAP.
они оба выполняют один и тот же подход абстракции связи, имея объекты заглушки, с которыми вы работаете, и примитивные/сложные типы данных, которые вы возвращаете, не зная, как все это обрабатывается под ним.
Я всегда предпочел бы (JSON-) RPC, потому что
хотя есть причины, по которым вы должны использовать SOAP, т.е. если вам нужны параметры именования вместо того, чтобы полагаться на их правильный порядок
некоторые дополнительные сведения, которые вы получаете из этого stackoverflow question