Разница между REST и WebServices

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

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

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

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

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

Ответ 1

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

Типичным WebService будет несколько методов 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 to mysite.com/products.asmx/UpdateProduct - изменяет продукт на основе SOAP XML в размещенном контенте

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

HTTP GET from mysite.com/products - возвращает XML или JSON, перечисляя все продукты
HTTP GET from 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 - добавляет новый продукт

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

Ответ 2

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

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

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