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

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

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

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

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

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

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

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

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

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

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

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

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

• Блог веб-сервисов Amazon: ОТДЫХ против SOAP
• Dare Obasanjo часто пишет о REST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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