Медленное и нестабильное интернет-соединение - SOAP vs REST - PullRequest
0 голосов
/ 10 февраля 2012

Я собираюсь внедрить веб-сервис в REST.
У меня огромная проблема в межконтинентальном соединении, которое иногда происходит медленно и нестабильно из-за потери пакетов.

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

Мой вопрос таков: поскольку оба они превышают http, есть ли разница, помимо размера данных, между обоими?Что бы вы использовали?

Ответы [ 3 ]

2 голосов
/ 10 февраля 2012

Как вы уже намекали, на самом деле это не вопрос SOAP или REST, а размер и частота сообщений.

Если протокол (количество, частота и структура сообщений) одинаков для REST и SOAP, то единственная реальная разница - это размер сообщения. Однако действительно проект системы RESTful может не иметь такой же схемы связи, как версия SOAP, потому что REST включает в себя манипулирование ресурсами, а не сообщения в методы в конечной точке. REST использует унифицированный набор стандартных глаголов (PUT, POST, GET, DELETE), в отличие от SOAP. Трудно сказать больше, не зная больше о вашем дизайне.

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

Ответы на этот вопрос также могут быть полезны.

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

0 голосов
/ 10 февраля 2012

Интерфейс SOAP можно сделать RESTful, поэтому я предполагаю, что вы думаете о SOAP против минималистического протокола (XML или JSON, без конверта).

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

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

В целом, я бы пошел с REST.

Тем не менее, если ваши сообщения большие и должны быть доставлены, SOAP может иметь преимущества. Лично мне больше нравится подход «одноразовые клиенты, серверы и сеть» с небольшими идемпотентными и не транзакционными сообщениями без сохранения состояния, когда мне это удается, но это делает разработку протокола более критичной.

0 голосов
/ 10 февраля 2012

Одно из различий между ними состоит в том, что существует стандарт WS-ReliableMessaging (внедренный WCF), который создает протокол, который гарантирует, что ваши сообщения приходят и что они приходят в правильном порядке. Если требуется надежная доставка сообщений даже в сети с потерями, то это SOAP огромное преимущество перед REST.

...