Разница между REST и веб-сервисами


в чем разница между REST и WebService (SOAP), я посмотрел на api facebook, они используют HTTP-заголовки и некоторые параметры (возможно, xml или нет) и возвращают результат в xml, где еще SOAP делает то же самое, HTTP-заголовки + xml-параметры и возвращает заголовки + xml.

REST также требует некоторого аутентифицированного токена, где еще SOAP использует сеанс http, который является точно таким же токеном, используемым для аутентификации и другой информации. Все, что я вижу, что мыло-это немного продвинутая версия REST?

или есть какие-либо другие соображения производительности? Чтение об отдыхе просто говорит о очень высоком уровне клиент-серверной связи, но даже SOAP делает то же самое. Может ли кто-нибудь указать мне, где он может определить правильную границу отдыха и мыла.

мы используем много мыла прозрачно в .net, однако я просто хочу знать, действительно ли стоит обратить внимание на отдых, где в настоящее время все работает исключительно гладко.

Я знаю, что отдых-это архитектура и SOAP-это протокол, но мой вопрос подробно, что в настоящее время ASP.NET реализация WebService SOAP имеет архитектуру REST?

2 55

2 ответа:

SOAP-это протокол для отправки / получения данных по HTTP в формате XML.

типичный веб-сервис будет несколько методов WSDL, который описывает, как его вызвать. Нет никакого реального соглашения о том, как они должны быть структурированы, поэтому вам всегда нужно много документации API.

обычно это будет что-то вроде (для ASP.NET):

  • HTTP POST to mysite.com/products.asmx/ListAllProducts - возвращает список XML продукты
  • HTTP POST to mysite.com/products.asmx/GetProduct - возвращает XML для продукта на основе SOAP XML в опубликованном содержимом
  • HTTP POST до mysite.com/products.asmx/UpdateProduct - изменения в продуктах, основанных на SOAP XML в размещенный контент

REST-это скорее Соглашение для структурирования всех ваших методов:

  • HTTP GET от mysite.com/products - возвращает XML или JSON список всех продуктов
  • HTTP GET от mysite.com/products/14 - возвращает XML или JSON для продукта 14
  • HTTP POST to mysite.com/products/14 - изменяет продукт 14 на то, что вы публикуете в HTML-форме.
  • HTTP DELETE to mysite.com/products/14 - удаляет продукт 14
  • HTTP PUT to mysite.com/products - добавляет новый продукт

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

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

Не уверен, что это полностью отвечает на ваш вопрос, но если, как вы говорите, у вас есть система, которая работает на основе мыла (и клиент и сервер), то я не вижу никаких причин для изменения. Кроме того, некоторые службы, естественно, больше подходят для доступа на основе RPC, и в этом случае интерфейс SOAP будет более подходящим.

с точки зрения производительности один или несколько слоев будут эффективно удалены с клиента и сервера технология стеки, если вы не используете SOAP, так что при прочих равных условиях, сервис, который предоставляет RESTful интерфейс выиграет там.