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

Question

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

RESTful Web Servcies

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

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

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

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

  $ users = Пользователи :: addUser ($ encryptedTrustToken, 'jim', $ encryptedPassword, 'James', 'Taylor');

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

Standard Web Services

Стандартный веб Servcies в конце концов в основном, делают то же самое. Единственное, что у них есть, это то, что клиент может открыть свои данные через 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 являются наиболее очевидным игроком. Здесь инструмент (datasvcutil.exe) предоставит вам полный контекст данных на стороне клиента с поддержкой LINQ. LINQ - это относительно новый способ создания сложных запросов .NET. Так что-то подобное (с сильным/проверки статического типа и IntelliSense):

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Позвольте мне знать, тоже, если я интерпретировать ваш вопрос ошибочно.

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

yc