Почему основанный на SOAP веб-сервис не является УСПОКОИТЕЛЬНЫМ?
Я понимаю УСПОКОИТЕЛЬНЫЙ, стиль архитектуры, но что точно заставляет основанный на SOAP веб-сервис не значить УСПОКОИТЕЛЬНЫЙ?
Это не ясно мне, какие точки ниже (из Википедии), не приспособлен SOAP.
- Клиент-сервер
- Не сохраняющий состояние
- Кэшируемый
- Многоуровневая система
- Код по требованию (дополнительно)
- Универсальный интерфейс
- Идентификация ресурсов
- Управление ресурсами через эти представления
- Самодокументированные сообщения
- Гиперсреда как механизм состояния приложения
Править: Я просто столкнулся с этим который сводки это вполне прилично.
REST не является RPC, RPC говорит, "определите некоторые методы, которые делают что-то", тогда как REST говорит, "определите некоторые ресурсы, и у них будут эти методы". Это - тонкое, но жизненное различие при предоставлении URI любой знает, что они могут взаимодействовать с ним через предопределенный набор методов и получить стандартные ответы HTTP в ответ. Так данный http://www.peej.co.uk/ я знаю, что могу проблема a Добираться на нем и получать что-то значимая спина. Я могу затем попробовать Поставивший это, чтобы изменить его и получить значимый код Ошибки HTTP, так как я не разрешен влезть в него.
4 ответа
SOAP следует образцу RPC. SOAP API описывает серию методов, а также их параметры и возвращаемые значения, которые можно вызвать из кода. Есть шаг маршала, который преобразует это в сетевое представление.
REST никогда не является RPC. REST API описывает серию ресурсов вместе с набором глаголов (обычно HTTP's GET, POST, PUT, DELETE), которые могут действовать на них.
Чтобы ответить на ваш вопрос напрямую: SOAP в первую очередь нарушает пункт 6 (он не предоставляет единого набора глаголов для всех API). Он также нарушает точку 2 (сервер может поддерживать состояние для каждого клиента), и, как результат, точку 3 (состояние предотвращает кэширование)
.REST и SOAP не являются эквивалентными понятиями.
REST:
- зависит от одного транспортного протокола (HTTP).
- Полностью использует специфические особенности этого протокола (глаголы GET, POST, PUT, DELETE, кэширование, заголовки и предопределенные коды ошибок).
- Ничего не говорит о формате сообщений, передаваемых туда и обратно.
- Ничего не говорит о формате сообщений, передаваемых туда и обратно. Однако, поскольку глагол HTTP и URL уже определяют действия, которые необходимо предпринять, тело сообщения должно содержать только данные.
- Безопасность сообщения обеспечивается транспортным протоколом (HTTPS), и является только "точка-точка". Если вы хотите обезопасить сообщение из конца в конец, вы должны сделать это самостоятельно.
- Первоначально предназначалось для простых операций CRUD над объектами.
SOAP:
- Независимо от транспортного протокола (могут быть HTTP, FTP, TCP, UDP, именованные трубы, общая память или даже электронная почта).
- Требуется только то, чтобы транспортный протокол мог отправлять и получать текст (например, на HTTP используется только POST глагол).
- Строго определяет формат сообщений, передаваемых туда и обратно. Сообщение SOAP содержит данные, действия, которые необходимо выполнить над ним, заголовки и детали ошибок в случае сбоя.
- Безопасность сообщений обеспечивается стандартами WS-* и является сквозной.
- Первоначально предназначено для произвольных вызовов RPC.
Пункты 2 и 3 в вышеприведенных списках являются основными точками несовместимости.
.Одной из целей REST является кэшируемость, для этого ресурс должен быть идентифицирован uri (строка запроса). На мыле запрос размещается, для разных запросов у вас одна и та же uri, и таким образом ресурс не может быть однозначно идентифицирован по ur
.