Сегодня мы посетили интересную демоверсию 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.
Некоторое релевантное чтение:
Я предполагаю, что когда вы говорите "веб-сервисы", вы имеете в виду SOAP и набор стандартов WS- *. (В противном случае я мог бы утверждать, что услуги REST являются "веб-сервисами".)
Канонический аргумент заключается в том, что службы REST более близки к дизайну сети, то есть к дизайну HTTP и связанной с ним инфраструктуры. Таким образом, использование службы REST будет более совместимо с существующими веб-инструментами и методами.
Конечно, как только вы перейдете к специфике, вы обнаружите, что оба подхода имеют сильные стороны в разных сценариях. Это те особенности, которые вас интересуют?
Накладные расходы не так важны, как хорошая архитектура.
REST не является протоколом, это архитектура, которая поощряет хороший масштабируемый дизайн. Он часто выбирается потому, что слишком большая свобода в RPC может легко привести к плохому дизайну.
Другая причина - предсказуемая стоимость протоколов RESTful через HTTP, поскольку она может использовать существующие технологии (в основном, прокси). Первоначальная стоимость RPC довольно низкая, но она значительно увеличивается при интенсификации нагрузки.
Почитал Роя Филдинг самым превосходным dissertation по этой теме. Он делает отличный случай и определенно WAY опережает свое время, когда писал (2000).
REST - это реализация-агностика и гораздо более прозрачная, и это отлично подходит для публичных API-интерфейсов, особенно для крупных веб-сайтов, таких как Flickr, Amazon или Digg, которые используют свои API как маркетинговые инструменты и действительно хотят, чтобы люди потребляли свои данные. Они не хотят быть тысячами новичков-новичков, которые пытаются отладить свой язык сценариев выбора из-за неправильной SOAP-библиотеки.
В сравнении с SOAP и WSDL, которые лучше подходят для внутренних приложений, где на обоих концах есть библиотеки выпадающих списков и известные знающие люди. (И вам, возможно, не нужно заботиться о вещах, таких как балансировка нагрузки в Интернете, кеширование HTTP и т.д.). Затем вы получаете API, которые являются самодокументированными, сохраняют типы и т.д. С нулевой работой.
Блог Стив Виноски и его последние статьи определенно заслуживает внимания. Он бывший гуру CORBA, который написал, вероятно, лучшую книгу на эту тему с Мичи Хеннинг, "Advanced CORBA® Programming with С++" . Тем не менее, с тех пор он видел ошибку своих клиентских/серверных способов и теперь клянется 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 проще реализовать, проще понять и повысить производительность.