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

Question

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

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

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

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

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

Answer 1

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

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

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

• HTTP POST до mysite.com / products.asmx / ListAllProducts - возвращает список продуктов XML
• HTTP POST до 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 до mysite.com / products / 14 - изменяет продукт 14 на то, что вы публикуете в HTML-форме.
• HTTP DELETE до mysite.com / products / 14 - удаляет продукт 14
• HTTP PUT до mysite.com / products - добавляет новый продукт

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

Answer 2

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

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

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