Чем RESTful и SOAP Web Services отличаются на практике?

Question

Я внедряю веб-службы для приложения PHP и пытаюсь понять, что могут предложить как стандартные веб-службы, так и веб-службы RESTful. Я намереваюсь написать код-обертку, чтобы абстрагировать детали веб-службы, чтобы разработчики могли просто «создавать экземпляры удаленных объектов» и использовать их. Вот мои мысли, возможно, некоторые из вас могли бы добавить свой опыт и расширить это:

Веб-службы RESTful

- это просто "XML-каналы по требованию", например, Вы можете написать код-обертку для клиентского приложения, чтобы оно могло запрашивать серверное приложение следующим образом:

$users = Users::getUsers("state = 'CO'");

• это, в свою очередь, приведет к получению XML-фида с удаленного URL
• $ пользователей может быть превращено в набор полных пользовательских объектов, или
• оставить как XML или
• превращается в массив и т. Д.
• сценарий запроса ("state = 'CO'") будет переведен в SQL на стороне сервера

• Веб-службы RESTful обычно доступны только для чтения с точки зрения клиента, хотя вы могли бы написать код, который мог бы использовать POST или GET для внесения изменений на сервере, например, Передача зашифрованного токена для безопасности, например ::1010

  $ users = Users :: addUser ($ encryptedTrustToken, 'jim', $ encryptedPassword, 'James', 'Taylor');

и это создаст нового пользователя на сервере приложения.

Стандартные веб-сервисы

Стандартные веб-сервисы в конце концов делают то же самое. Единственное преимущество, которое у них есть, заключается в том, что клиент может узнать свои данные через WSDL. Но кроме этого, если я хочу написать код-обертку, который позволяет разработчику создавать, редактировать и сохранять объекты удаленно, мне все равно нужно реализовать код-обертку. SOAP ничего не делает для меня, он может сделать это:

$soap = new nusoap_client('http://localhost/test/webservice_user.php?wsdl', true);
$user = $soap->getProxy(); 
$lastName = $user->lastName();

но если я хочу отредактировать и сохранить:

$user->setLastName('Jones');
$user->save();

тогда мне нужно, например, обрабатывать все состояния на стороне сервера, SOAP, похоже, не содержит этот объект на стороне сервера для каждого клиента.

Возможно, есть ограничения в реализации PHP SOAP, которую я использую (nusoap). Возможно, реализации Java и .NET делают намного больше.

Будет приятно услышать ваши отзывы, чтобы очистить некоторые из этих облаков.

Answer 1

Это разные модели ... REST - , ориентированный на данные , где SOAP - , ориентированный на работу . то есть с SOAP вы, как правило, имеете дискретные операции «SubmitOrder» и т.д .; но с REST вы, как правило, гораздо лучше понимаете, как запрашивать данные.

SOAP также имеет тенденцию ассоциироваться с гораздо большей сложностью (что иногда необходимо) - REST возвращается к POX и т. Д., И YAGNI .

---

В терминах .NET такие инструменты, как "wsdl.exe", предоставят вам полную прокси-библиотеку на стороне клиента для представления службы SOAP (или "svcutil.exe" для службы WCF):

var someResult = proxy.SubmitOrder(...);

Я полагаю, что для REST с .NET ADO.NET Data Services является наиболее очевидным игроком. Здесь инструмент (datasvcutil.exe) предоставит вам полный контекст данных на стороне клиента с поддержкой LINQ. LINQ - это относительно новый способ .NET для формирования сложных запросов. Так что-то вроде (со строгой / статической проверкой типов и intellisense):

var qry = from user in ctx.Users
          where user.State == 'CO'
          select user;

(это будет переведено в / из соответствующего синтаксиса REST для служб данных ADO.NET)

Answer 2

Я повторяю то, что упомянул Марк Гравелл. Когда люди спрашивают меня о REST (и они обычно имеют представление о SOAP и SOA), я отвечаю им, что REST = ROA, поскольку он ориентирован на ресурсы / данные, это другая парадигма и, следовательно, другие проблемы проектирования.

В вашем случае, если я правильно вас читаю, вы хотите избежать написания кода-обертки и нуждаетесь в решении, которое может хранить объекты и их атрибуты удаленно (и полностью скрывать их от разработчиков). Я не могу действительно предложить лучшее решение .. Хмм, дайте мне знать, если какой-либо из них когда-либо приблизится к вашим требованиям:

1. EJB3 / JPA
2. CouchDB (REST / JSON)

Дайте мне знать, если я неправильно истолковал ваш вопрос.

Если мы сравним XML-RPC и SOAP, последний даст вам лучшую обработку типов данных, для первых, хотя вы будете иметь дело с более простыми типами данных, но вам придется написать слой или адаптер для преобразования их в ваш домен объекты.

Ус

Answer 3

Soap - это просто набор согласованных XML-схем, благословленных группой стандартов. Его сила в том, что он был разработан для обеспечения совместимости и поддерживает множество функций корпоративного класса. Мыло на любой платформе не обеспечит операции, которые вы ищете. Вам необходимо разработать и внедрить сервисный контракт, чтобы получить эти функции.

Звучит так, будто вам нужны удаленные объекты, для которых ни Soap, ни REST особенно не подходят Может быть, вам лучше взглянуть на XML-RPC .

Answer 4

Мой отзыв таков: если вы хотите удаленное состояние, вы не говорите о веб-сервисах. Я не знаю ни о какой современной модели, которая имеет дело с удаленным состоянием. Я думаю, что если вам нужно удаленное государство, вы сами по себе (без религии, чтобы следовать). Просто бросьте xml отсюда туда и не обращайте внимания на теорию.

Я должен добавить, что отдаленное состояние - зло. Избегайте этого, если можете.

Answer 5

Основные отличия в основном инструментальные.

Многие высокопроизводительные стеки SOAP скрывают большую часть инфраструктуры SOAP от разработчика, где вы работаете в значительной степени исключительно с DTO / Documents and RPC.

REST через HTTP возлагает на вас большую нагрузку на разработчика (согласование форматов [XML, JSON, HTTP POST], анализ результатов [DOM, карты, DTO-маршаллинг и т. Д.]).

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