Как сервис на основе 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 описывает следующие шесть ограничений, применяемых к архитектуре, оставляя при этом реализацию отдельных компонентов, которые могут быть запроектированы:

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

сравнение

На мой взгляд, это не следует описывать как 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.