Как сервис на основе SOAP можно рассматривать как частный случай службы REST-стиля?

Цитата из Java Web Services: Up And Running, Second Edition:

"В настоящее время различие между двумя вариантами веб-службы не является резким, потому что служба на основе SOAP, предоставляемая через HTTP, может рассматриваться как частный случай службы REST-стиля";

Как?

1 ответ

Как?

Я считаю, что выражение автора неверно.

Что такое SOAP?

Согласно википедии:

SOAP может формировать базовый уровень стека протоколов веб-сервисов, предоставляя базовую платформу обмена сообщениями, на которой могут быть созданы веб-службы. Этот XML-протокол состоит из трех частей: конверта, который определяет, что находится в сообщении, и как его обрабатывать, набор правил кодирования для выражения экземпляров типов данных, определенных приложением, и соглашение для представления вызовов процедур и ответов. SOAP имеет три основные характеристики: расширяемость (безопасность и WS-маршрутизация входят в число разрабатываемых расширений), Neutrality (SOAP может использоваться по любому транспортному протоколу, такому как HTTP, SMTP, TCP или JMS) и независимость (SOAP допускает любое программирование модель).

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

Напротив, у нас есть REST.

Что такое REST?

Согласно википедии:

Архитектурный стиль REST описывает следующие шесть ограничений, применяемых к архитектуре, оставляя при этом реализацию отдельных компонентов, которые могут быть запроектированы:

<ul> <li> <span>Клиент-сервер:</span> серверы не связаны с пользовательским интерфейсом или пользовательским состоянием, поэтому серверы могут быть более простыми и масштабируемыми.</li> <li> <span>Безстоящий: связь</span> клиент-сервер дополнительно ограничена отсутствием клиентского контекста на сервере между запросами.</li> <li> <span>Cacheable:</span> Ответы должны, неявно или явно, определять себя как кэшируемые или нет, чтобы предотвратить повторное использование клиентами устаревших или несоответствующих данных в ответ на дальнейшие запросы.</li> <li> <span>Многоуровневая система:</span> клиент не может обычно указывать, подключен ли он непосредственно к конечному серверу или к посреднику на этом пути. Промежуточные серверы могут улучшить масштабируемость системы за счет включения балансировки нагрузки и предоставления общих кэшей.</li> <li> <span>Код по запросу (необязательно):</span> серверы могут временно расширять или настраивать функциональные возможности клиента путем передачи исполняемого кода.</li> <li> <span>Единый интерфейс:</span> единообразный интерфейс между клиентами и серверами, обсужденный ниже, упрощает и отделяет архитектуру, которая позволяет каждой части развиваться независимо. (т.е. HTTP GET, POST, PUT, PATCH, DELETE)</li> </ul>

сравнение

На мой взгляд, это не следует описывать как SOAP vs REST, это должен быть RPC vs REST. RPC - это удаленный процедурный вызов, который в основном означает, что каждая отдельная функциональность вашего API получает 1 отличную конечную точку API и так далее. поэтому REST может сделать с 1 url, что RPC делает с 7. SOAP - RPC (правильно?)

Да, оба являются веб-службами.

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

В заключение, мне нужно больше контекста, чтобы понять, в какой момент автор пытался это сделать. API RPC может быть похож на REST, если вы делаете это RESTful, но это действительно косвенно, не так ли?

licensed under cc by-sa 3.0 with attribution.