Зачем использовать REST вместо сервисов на основе SOAP? [закрыто]

153

Сегодня я посетил интересную демонстрацию по REST, но я не мог придумать ни одной причины (и не был представлен), почему REST в любом случае лучше или проще в использовании и реализации, чем стек сервисов на основе SOAP.

Каковы некоторые из причин, почему кто-либо в «реальном мире» использует REST вместо Сервисов на основе SOAP?

AngryHacker
источник
37
Под веб-сервисами вы имеете в виду веб-сервисы в стиле SOAP? Потому что, насколько я знаю, у вас могут быть и веб-сервисы RESTful.
Джеймс МакМахон

Ответы:

160

Меньше накладных расходов (без конверта SOAP, чтобы обернуть каждый вызов)

Меньше дублирования (HTTP уже представляет такие операции, как DELETE, PUT, GET и т. Д., Которые в противном случае должны быть представлены в конверте SOAP).

Более стандартизирован - операции HTTP хорошо поняты и работают согласованно. Некоторые реализации SOAP могут стать привередливыми.

Более удобочитаемым и тестируемым (сложнее тестировать SOAP только с помощью браузера).

Не нужно использовать XML (ну, для SOAP это тоже не обязательно, но это вряд ли имеет смысл, поскольку вы уже выполняете анализ конверта).

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

Кендалл Хельмштеттер Гелнер
источник
1
Я хотел бы добавить, что межплатформенное взаимодействие SOAP также может быть PITA (разве это не было частью SOAP?!?).
Джастин Бозонье
7
Также отлично работает с HTTP-инфраструктурой - например, GET активно кэшируются вместе с использованием последних модифицированных и etags
Джеймс
Отличная работа с веб-браузерами для предоставления универсального клиента вашим услугам также помогает :)
Джеймс Стрэчен
2
Я бы сказал, что SOAP хорошо стандартизирован. Если вы имеете в виду, что реализации являются незрелыми, то, возможно, было бы хорошо сделать это более ясным. Я бы оценил некоторые доказательства этой точки зрения, если вы предлагаете это. Я также хотел бы задать вопрос, является ли REST более читабельным для человека, это полностью зависит от того, как вы решите форматировать контент. Также помните, что XML предназначен для чтения человеком, хотя и многословен, как мы все знаем.
Говард
6
HTTP так же стандартизирован, как и SOAP, и существует дольше, поэтому реализации действительно стабильны и действительно совместимы. SOAP также будет менее читаемым даже при наличии идентичного контента, поскольку конверт в него заключен. На практике за последние несколько лет я обнаружил, что JSON через HTTP является наилучшей комбинацией, достаточно читаемой, хотя еще более компактный.
Кендалл Хельмштеттер Гелнер
36

Сервисы RESTful гораздо проще использовать, чем сервисы на основе SOAP . Причина этого заключается в том, что REST основан на обычных HTTP-запросах, что позволяет определить намерение по типу выполняемого запроса (GET = retrive, POST = write, DELETE = remove и т. Д.) И полностью не имеет состояния. С другой стороны, вы можете утверждать, что он менее гибок, так как избавляется от концепции конверта сообщения, содержащего контекст запроса.

По моему опыту, SOAP предпочтительнее для сервисов внутри предприятия, а REST - для сервисов, предоставляемых в виде общедоступных API.

С такими инструментами, как WCF в .NET Framework, очень просто реализовать сервис как REST или SOAP.

Некоторое уместное чтение:

Эрик Шуновер
источник
9
Насколько я понимаю, файлы WSDL могут использоваться для генерации классов для предоставления методов веб-службы. Конечно, это делает потребление услуг столь же простым, как вызов функции? Можете ли вы объяснить свою точку зрения еще, пожалуйста.
Говард
1
Говард Мэй: Предполагая, что вы вызываете функции, используя только примитивные типы данных, это, безусловно, верно. Но в этом случае вы не можете утверждать, что SOAP проще, чем отдых. Если у вас сложные типы данных, обработка WSDL может нормально работать между двумя компьютерами с одинаковыми стеками WS. Но у вас неизбежно возникнут проблемы, как только вы смешаете стеки. Это перестает быть таким простым, как только вы начинаете копаться в WSDL вручную для устранения несовместимостей.
Джозеф Холстен
1
В 2014 году почти все платформы, даже древние, поддерживают WSDL. Прокси-классы делают использование API чрезвычайно простым. Мы внедряем push-сервис, и я рассматриваю REST, но мне действительно трудно увидеть какую-либо выгоду
JohnOpincar
13

Я предполагаю, что когда вы говорите «веб-сервисы», вы имеете в виду SOAP и набор стандартов WS- *. (В противном случае я могу утверждать, что REST-сервисы являются «веб-сервисами».)

Каноническим аргументом является то, что REST-сервисы более близки к дизайну сети, то есть к дизайну HTTP и связанной инфраструктуры. Таким образом, использование службы REST будет более совместимым с существующими веб-инструментами и методами.

Конечно, как только вы углубитесь в детали, вы обнаружите, что оба подхода имеют свои сильные стороны в разных сценариях. Вас интересует именно эта специфика?

Брюс
источник
10

Накладные расходы не так важны, как хорошая архитектура.

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

Другая причина - предсказуемая стоимость протоколов RESTful по HTTP, поскольку она может использовать существующие технологии (в основном, прокси). Начальная стоимость RPC довольно низкая, но она имеет тенденцию значительно увеличиваться с увеличением нагрузки.

Петр Чапла
источник
7

REST не зависит от реализации и гораздо более прозрачен, что делает его отличным для общедоступных API, особенно для больших веб-сайтов, таких как Flickr, Amazon или Digg, которые используют свои API в качестве маркетинговых инструментов и действительно хотят, чтобы люди использовали их данные. Они не хотят держать в руках тысячи начинающих разработчиков, которые пытаются отладить язык сценариев по своему выбору с ошибочной библиотекой SOAP.

По сравнению с SOAP и WSDL, которые лучше подходят для внутренних приложений, где у вас есть встроенные библиотеки и знакомые люди с обеих сторон. (И вам, возможно, не нужно заботиться о таких вещах, как балансировка нагрузки в масштабах Интернета, кэширование HTTP и т. Д.). Затем вы получаете API, которые документируются самостоятельно, сохраняют типы и т. Д. С нулевой нагрузкой.

joelhardi
источник
Хороший ответ, но я бы не согласился с тем, что SOAP означает, что у вас не может быть балансировки нагрузки в масштабе Интернета.
HDave
7

Надо прочитать самую превосходную диссертацию Роя Филдинга на эту тему. У него отличный пример, и он определенно намного опередил свое время, когда написал его (2000).

Piko
источник
6

Блог Стива Виноски и его последние статьи определенно заслуживают изучения. Он - бывший гуру CORBA, который написал, вероятно, лучшую книгу по этому вопросу с Мичи Хеннинг, «Расширенное программирование на CORBA® на C ++» . Тем не менее, он с тех пор видел ошибку своих клиент-серверных путей, и теперь ругается на REST.

Джейсон Этеридж
источник
5

REST позволяет кэшировать ваши операции без мутаций (которые обычно используют глагол GET) . То есть кэшируется клиентом и / или кэшируется прокси. Это может быть огромной победой!

Дэвид
источник
8
Это просто «правильно использовать HTTP», а не REST.
aehlke
3

REST - это просто способ реализации веб-сервисов. Это просто способ правильно использовать HTTP для запроса веб-сервисов, на которые вы пытаетесь попасть.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

Эрик Холшер
источник
1
REST не имеет ничего общего с HTTP и полностью независим от протокола. Тем не менее, он хорошо подходит для некоторых типов веб-сервисов, ориентированных на ресурсы.
aehlke
0

Это супер просто и стройно. Вы можете сделать это с помощью браузера через http глагол: GET. Я не нашел браузер, который мог бы легко сделать общий запрос HTTP POST

Рэй Лу
источник
1
Оформить заказ Fiddler. Это не браузер, но это отличный способ создавать HTTP POST без кода. fiddler2.com/fiddler2
Эрик Шуновер
Я обычно делаю это с изменением существующего запроса с Чарльзом. У меня тоже есть скрипач.
Рэй Лу
0

Вот одна точка данных: Amazon предлагает свои API в форматах REST и SOAP, и 85% использования - это REST.

REST легче реализовать, легче понять и повысить производительность.

pbreitenbach
источник
7
Есть ли у вас какие-либо ссылки для вашего заявления «более высокой производительности»?
Джеймс МакМахон
3
Где вы получили 85% использования? Это очень полезно знать (если я смогу увидеть доказательства)
schmoopy
3
Ручное чтение спецификации API, печать страниц и т. Д. Проще в реализации, чем «Правый клик, Добавить ссылку на сервис»? (VS2010)
BlueChippy
@schmoopy Из блога Amazon: aws.typepad.com/aws/2005/09/rest_vs_soap.html
joerage