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

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

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

 James McMahon18 февр. 2010 г., 16:26
Под веб-сервисами вы имеете в виду веб-сервисы в стиле SOAP? Потому что, насколько я знаю, у вас могут быть и веб-сервисы RESTful.

Ответы на вопрос(11)

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

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

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

REST проще в реализации, проще для понимания и более высокой производительности.

 schmoopy26 янв. 2012 г., 20:48
Где вы получили 85% использования? Это очень хорошо знать (если я вижу доказательства)
 James McMahon18 февр. 2010 г., 16:28
Есть ли у вас какие-либо ссылки на ваше заявление о «более высокой производительности»?
 BlueChippy15 окт. 2012 г., 07:08
Ручное чтение спецификации API, печать страниц и т. Д. Проще в реализации, чем «Правый клик, Добавить ссылку на сервис»? (VS2010)
 joerage01 мар. 2014 г., 21:03
@schmoopy из блога Amazon:aws.typepad.com/aws/2005/09/rest_vs_soap.html

диссертация по теме. Он делает отличный случай и был определенноПУТЬ опередил свое время, когда он написал это (2000).

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

 aehlke20 июл. 2009 г., 19:57
Это просто «правильно использовать HTTP», а не REST.

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

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

 aehlke20 июл. 2009 г., 19:56
REST не имеет ничего общего с HTTP и полностью независим от протокола. Тем не менее, он хорошо подходит для некоторых типов ресурс-ориентированных веб-сервисов.

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

 Ray Lu26 окт. 2008 г., 12:08
Я обычно делаю это с изменением существующего запроса с Чарльзом. У меня тоже есть скрипач.
 Eric Schoonover18 сент. 2008 г., 08:44
Оформить заказ Fiddler. Это не браузер, но это отличный способ создавать HTTP POST без кода.fiddler2.com/fiddler2
Решение Вопроса

чтобы обернуть каждый вызов)

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

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

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

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

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

 Howard May11 мая 2009 г., 18:07
Я бы сказал, что SOAP хорошо стандартизирован. Если вы имеете в виду, что реализации являются незрелыми, то, возможно, было бы хорошо сделать это более ясным. Я бы оценил некоторые доказательства этой точки зрения, если вы предлагаете это. Я также хотел бы задать вопрос, является ли REST более читабельным для человека, это полностью зависит от того, как вы решите форматировать свой контент. Также помните, что XML предназначен для чтения человеком, хотя и многословен, как все мы знаем.
 Kendall Helmstetter Gelner15 сент. 2010 г., 18:53
HTTP так же стандартизирован, как и SOAP, и существует дольше, поэтому реализации действительно стабильны и действительно совместимы. SOAP также будет менее читаемым даже при наличии идентичного контента, поскольку конверт в него заключен. На практике за последние несколько лет я обнаружил, что JSON через HTTP является наилучшей комбинацией, достаточно читаемой, хотя еще более компактный.
 James Strachan18 сент. 2008 г., 11:05
Также отлично работает с HTTP-инфраструктурой - например, GET агрессивно кэшируются вместе с использованием последних модифицированных и etags
 James Strachan18 сент. 2008 г., 11:05
Отличная работа с веб-браузерами для предоставления универсального клиента вашим услугам также помогает :)
 Justin Bozonier18 сент. 2008 г., 09:14
Я хотел бы добавить, что межплатформенное взаимодействие SOAP также может быть PITA (разве это не было частью SOAP?!?).

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

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

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

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

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

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

 HDave16 нояб. 2011 г., 21:19
Хороший ответ, но я бы не согласился с тем, что SOAP означает, что у вас не может быть балансировки нагрузки в масштабе Интернета.

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

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

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

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

Блог веб-сервисов Amazon: ОТДЫХ против SOAPDare Obasanjo часто пишет о REST
 JohnOpincar30 янв. 2014 г., 23:04
В 2014 году почти все платформы, даже древние, поддерживают WSDL. Прокси-классы делают использование API чрезвычайно простым. Мы внедряем услугу push, и я рассматриваю REST, но мне действительно трудно увидеть какую-либо выгоду.
 Joseph Holsten05 сент. 2009 г., 00:27
Говард Мэй: Предполагая, что вы вызываете функции, используя только примитивные типы данных, это, безусловно, верно. Но в этом случае вы не можете утверждать, что SOAP проще, чем отдых. Если у вас сложные типы данных, обработка WSDL может нормально работать между двумя компьютерами с одинаковыми стеками WS. Но у вас неизбежно возникнут проблемы, как только вы смешаете стеки. Это перестает быть таким простым, как только вы начинаете копаться в WSDL вручную для устранения несовместимостей.
 Howard May11 мая 2009 г., 18:10
Насколько я понимаю, файлы WSDL могут использоваться для генерации классов для предоставления методов веб-службы. Конечно, это делает потребление услуг столь же простым, как вызов функции? Можете ли вы объяснить свою точку зрения еще, пожалуйста.

Ваш ответ на вопрос