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

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

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

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

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

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

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

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

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



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

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



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

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



[диссертация](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) по теме. Он делает отличный случай и был определенно**ПУТЬ** опередил свое время, когда он написал это (2000).



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



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

<http://www.xfront.com/REST-Web-Services.html> [http://en.wikipedia.org/wiki/Representational\_State\_Transfer](https://en.wikipedia.org/wiki/Representational_State_Transfer)



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



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

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

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



[Блог Стива Виноски](http://steve.vinoski.net/blog/) и его[Последние статьи](http://steve.vinoski.net/blog/internet-computing-columns/) безусловно, стоит прочитать. Он бывший гуру CORBA, который написал, вероятно, лучшую книгу на эту тему с Мичи Хеннинг,[«Расширенное программирование на CORBA на C ++»](http://www.informit.com/store/product.aspx?isbn=0201379279), Однако с тех пор он видел ошибку своих клиент-серверных путей и теперь ругается по REST.



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

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



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

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

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

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

[Блог веб-сервисов Amazon: ОТДЫХ против SOAP](http://aws.typepad.com/aws/2005/09/rest_vs_soap.html)[Dare Obasanjo часто пишет о REST](https://www.google.com/search?q=rest+site%3A25hoursaday.com&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)