Чем на практике отличаются веб-службы RESTful и SOAP?

StackOverflow https://stackoverflow.com/questions/296116

Вопрос

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

Веб-сервисы RESTful

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

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

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

    $users = Users::addUser($encryptedTrustToken, 'Джим', $encryptedPassword, 'Джеймс', 'Тейлор');

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

Стандартные веб-службы

Стандартные веб-сервисы, в конечном итоге, делают то же самое.Единственное их преимущество заключается в том, что клиент может узнать свои данные через 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 делают гораздо больше.

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

Это было полезно?

Решение

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

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

С точки зрения .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)

Другие советы

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

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

  1. EJB3/JPA
  2. CouchDB (ОТДЫХ/JSON)

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

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

yc

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

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

Ключевые различия в основном заключаются в инструментах.

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top