Зачем использовать REST вместо SOAP-сервисов? [закрытый]
посетил интересную демонстрацию на REST сегодня, однако, я не мог придумать ни одной причины (и не был представлен), почему REST в любом случае лучше или проще в использовании и реализации, чем стек сервисов на основе SOAP.
Каковы некоторые из причин, по которым кто-либо в" реальном мире " использует REST вместо SOAP-сервисов?
11 ответов
меньше накладных расходов (нет конверта мыла, чтобы обернуть каждый вызов)
меньше дублирования (HTTP уже представляет операции, такие как DELETE, PUT, GET и т. д. которые в противном случае должны быть представлены в конверте SOAP).
более стандартизированные-операции HTTP хорошо поняты и работают последовательно. Некоторые реализации SOAP могут стать привередливыми.
более читаемый и тестируемый человеком (сложнее тестировать SOAP только с помощью браузера).
не нужно использовать XML (ну, вам вроде как не нужно для мыла, но это вряд ли имеет смысл, так как вы уже делаете разбор конверта).
библиотеки сделали SOAP (вид) легким. Но вы абстрагируете много избыточности, как я уже отметил. да, теоретически SOAP может проходить через другие транспорты, чтобы избежать езды на слое, делая подобные вещи, но на самом деле почти вся работа с мылом, которую вы когда-либо будете делать, - это HTTP.
RESTful услуги гораздо проще потреблять, чем мыло на основе (регулярные) услуги. Причина этого заключается в том, что REST основан на обычных HTTP-запросах, которые позволяют выводить намерение из типа запроса (GET = retrive, POST = write, DELETE = remove и т. д...) и полностью без гражданства. С другой стороны, вы можете утверждать, что он менее гибкий, поскольку он устраняет концепцию конверта сообщения, содержащего запрос контекст.
по моему опыту SOAP был предпочтительным для служб внутри предприятия, а REST был предпочтительным для служб, которые представлены как общедоступные API.
с такими инструментами, как WCF в .NET framework, очень тривиально реализовать службу как REST или SOAP.
некоторые соответствующие значение:
Я предполагаю, что когда вы говорите "веб-службы", вы имеете в виду SOAP и набор стандартов WS -*. (В противном случае я мог бы утверждать, что REST services are "веб-сервисы".)
канонический аргумент заключается в том, что службы REST ближе соответствуют дизайну web - то есть дизайну HTTP и связанной инфраструктуры. Таким образом, использование сервиса REST будет более совместимо с существующими веб-инструментами и методами.
конечно, как только вы сверлите в особенности, вы обнаружите, что оба подхода имеют сильные стороны в разных сценариях. Вас интересуют эти особенности?
накладные расходы не так важны, как и хорошая архитектура.
REST-это не протокол, это архитектура, которая поощряет хороший масштабируемый дизайн. Он часто выбирается, потому что слишком большая свобода в RPC может легко привести к плохому дизайну.
другая причина-предсказуемая стоимость протоколов RESTful через HTTP, поскольку она может использовать существующие технологии (в основном прокси). Начальная стоимость RPC довольно низкая, но она, как правило, значительно увеличивается с нагрузкой усиление.
REST-это реализация-агностик и гораздо более прозрачный, и это делает его отличным для публичных API, особенно для больших веб-сайтов, таких как Flickr, Amazon или Digg, которые используют свои API в качестве маркетинговых инструментов и действительно хотят, чтобы люди потребляли свои данные. Они!--1-->не хотите быть ручным 1000-х начинающих разработчиков, которые пытаются отладить их скриптовый язык выбора багги SOAP библиотеки.
по сравнению с SOAP и WSDL, которые лучше для внутренних приложений, где у вас есть библиотеки и известные невежественные люди на обоих концах. (И вам, возможно, не нужно заботиться о таких вещах, как балансировка нагрузки в Интернете, кэширование HTTP и т. д.) Затем вы получаете API, которые являются само документированными, сохраняют типы и т. д. с нулевой работой.
должен прочитать самый превосходный Рой Филдинг диссертации по теме. Он делает отличный случай и был определенно путь опередил свое время, когда он писал это (2000).
Стив Vinoski блог и его последние статьи определенно стоит ознакомиться. Он бывший гуру КОРБЫ, который написал, вероятно, лучшую книгу на эту тему с Мичи Хеннинг, " расширенное Программирование CORBA® на C++". Тем не менее, с тех пор он видел ошибку своих клиентских/серверных способов, и теперь клянется покоем.
REST позволяет вашим не мутирующим операциям (которые обычно используют глагол GET) быть кэшированные. То есть кэшируется клиентом и/или кэшируется прокси-серверами. Это может быть огромная победа!
REST-это в основном просто способ реализации веб-сервисов. Это просто способ правильно использовать HTTP для запроса веб-служб, которые вы пытаетесь ударить.
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
Это супер простой и тонкий. Вы можете сделать это с помощью браузера через HTTP verb: GET. Я не нашел браузер, который может вручную выполнить общий запрос http POST легко
вот одна точка данных: Amazon предлагает свои API в форматах REST и SOAP, а 85% использования-REST.
REST легче реализовать, легче понять и более высокую производительность.