xml - чайников - soap vs rest




SOAP или REST для веб-служб? (19)

Является ли REST лучшим подходом к веб-сервисам или SOAP? Или они разные инструменты для разных проблем? Или это тонкая проблема - то есть, она немного лучше на некоторых аренах, чем другая, и т. Д.?

Баунти-Edit:

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


REST - принципиально другая парадигма SOAP. Хорошее чтение в REST можно найти здесь: Как я объяснил REST моей жене .

Если у вас нет времени на его чтение, вот короткая версия: REST - это немного смещение парадигмы, сосредоточившись на «существительных» и ограничивая количество «глаголов», которые вы можете применить к этим существительным. Единственными допустимыми глаголами являются «get», «put», «post» и «delete». Это отличается от SOAP, где многие разные глаголы могут применяться ко многим различным существительным (т. Е. К множеству разных функций).

Для REST четыре глагола сопоставляются с соответствующими HTTP-запросами, тогда как существительные идентифицируются по URL-адресам. Это делает управление государством гораздо более прозрачным, чем в SOAP, где его часто неясно, какое состояние находится на сервере и что находится на клиенте.

На практике, хотя большая часть этого отпадает, и REST обычно просто ссылается на простые HTTP-запросы, которые возвращают результаты в JSON , тогда как SOAP - это более сложный API, который обменивается данными путем передачи XML. У обоих есть свои преимущества и недостатки, но я обнаружил, что, по моему опыту, REST - это, как правило, лучший выбор, потому что вам редко требуется полная функциональность, которую вы получаете от SOAP.


REST - это архитектура, SOAP - это протокол.

Это первая проблема.

Вы можете отправлять конверты SOAP в приложение REST.

Сам SOAP на самом деле довольно простой и простой, именно стандарты WSS- * поверх него делают его очень сложным.

Если ваши потребители являются другими приложениями и другими серверами, сегодня существует много поддержки протокола SOAP, и основы перемещения данных по сути являются щелчком мыши в современных IDE.

Если ваши потребители более склонны быть клиентами RIA или Ajax, вам, вероятно, понадобится что-то более простое, чем SOAP, и более привычное для клиента (в частности, JSON).

Пакеты JSON, передаваемые по HTTP, не обязательно являются архитектурой REST, это просто сообщения для URL-адресов. Все отлично работает, но есть ключевые компоненты для идиомы REST. Однако их легко спутать. Но только потому, что вы говорите, HTTP-запросы не обязательно означают, что у вас есть архитектура REST. У вас может быть приложение REST без HTTP вообще (разум, это редко).

Итак, если у вас есть серверы и потребители, которые «удобны» с SOAP, то SOAP и WSS-стек могут служить вам хорошо. Если вы делаете больше специальных действий и хотите лучше взаимодействовать с веб-браузерами, тогда может работать и более легкий протокол по протоколу HTTP.


SOAP полезен с точки зрения инструментария, потому что WSDL так легко потребляется инструментами. Таким образом, вы можете получить клиентов Web-сервиса, сгенерированных для вас на вашем любимом языке.

REST хорошо работает с веб-страницами AJAX'y. Если ваши запросы просты, вы можете совершать служебные звонки непосредственно с вашего JavaScript, и это очень удобно. Старайтесь держаться подальше от каких-либо пространств имен в ответе XML, я видел, как браузеры задыхаются от них. Таким образом, xsi: type, вероятно, не сработает для вас, не слишком сложных XML-схем.

REST также имеет лучшую производительность. Требования к процессору генерирующих код REST-ответов, как правило, ниже, чем показывают структуры SOAP. И, если у вас есть утки для генерации XML, выстроенные на стороне сервера, вы можете эффективно передавать XML клиенту. Итак, представьте, что вы читаете строки курсора базы данных. Когда вы читаете строку, вы отформатируете ее как элемент XML, и вы пишете это непосредственно пользователю службы. Таким образом, вам не нужно собирать все строки базы данных в памяти, прежде чем начинать писать свой XML-вывод - вы одновременно читаете и пишете. Изучите новые шаблоны двигателей или XSLT, чтобы потоковая передача работала для REST.

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

Мой процесс принятия решений выглядит следующим образом: если я хочу, чтобы мой сервис был легко утилизирован потребителями, а сообщения, которые я пишу, будут от среднего до малого (10 МБ или меньше), и я не против сжигания дополнительного процессора циклов на сервере, я иду с SOAP. Если мне нужно будет обслуживать AJAX в веб-браузерах, или мне нужно, чтобы поток был потоком, или мои ответы велики, я иду REST.

Наконец, существует множество отличных стандартов, созданных вокруг SOAP, таких как WS-Security и получение состояния Web-сервисов, которые вы можете подключить, если вы используете нужные инструменты. Такой материал действительно имеет значение и может помочь вам удовлетворить некоторые волосатые требования.


Большинство приложений, которые я пишу, это серверные C # или Java, или настольные приложения в WinForms или WPF. Эти приложения, как правило, нуждаются в более богатом API услуг, чем может предоставить REST. Кроме того, я не хочу тратить больше, чем пару минут на создание моего клиента веб-сервиса. Инструменты создания клиента обработки WSDL позволяют мне реализовать моего клиента и перейти к добавлению стоимости бизнеса.

Теперь, если я пишу веб-службу явно для некоторых javascript-вызовов ajax, это, вероятно, будет в REST; просто ради знания технологии клиента и использования JSON. На мой взгляд, API-интерфейсы веб-сервисов, используемые из javascript, вероятно, не должны быть очень сложными, так как этот тип сложности лучше обрабатывается на стороне сервера.

С учетом сказанного, есть некоторые SOAP-клиенты для javascript; Я знаю, что у jQuery есть один. Таким образом, SOAP можно использовать из javascript; просто не так хорошо, как служба REST, возвращающая строки JSON. Поэтому, если у меня есть веб-сервис, который я хотел бы быть достаточно сложным, чтобы он был гибким для произвольного количества клиентских технологий и применений, я бы пошел с SOAP.


В смысле с PHP-юниверсом поддержка PHP для любого продвинутого SOAP отнимает большое время. В результате вы будете использовать что-то вроде http://wso2.com/products/web-services-framework/php/ как только вы перейдете основные потребности, даже если WS-Security или WS-RM не поддерживают встроенную поддержку.

Создание конверта SOAP. Я чувствую, что PHP очень запутан, так как он создает пространства имен, xsd: nil, xsd: anytype и старые стильные мыльные сервисы, которые используют SOAP Encoding (Бог знает, как это отличается) в сообщениях SOAP.

Избегайте всего этого беспорядка, придерживаясь REST, REST - это не что-то большое, что мы использовали с самого начала WWW. Мы поняли, что только когда вышла эта статья http://www.ics.uci.edu/~fielding/pubs/dissustry/top.htm , она показывает, как мы можем использовать возможности HTTP для реализации служб RESTFul. HTTP по сути является REST, что не означает, что просто использование HTTP делает ваши сервисы RESTFul.

SOAP игнорирует основные возможности HTTP и рассматривает HTTP так же, как транспортный протокол, следовательно, он является независимым от транспортного протокола в теории (на практике это не так, вы слышали о SOAP Action header? Если не google сейчас!).

С увеличением JSON-адаптации и HTML5 с javascript созревание REST с JSON стало наиболее распространенным способом работы с сервисами. Также была определена схема JSON, которая может быть использована для решения на уровне предприятия (все еще на ранних стадиях) вместе с WADL, если это необходимо.

Поддержка PHP для REST и JSON определенно лучше, чем существующая встроенная поддержка SOAP.

Добавление нескольких слов BUZZ здесь SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

кстати, я действительно люблю SOAP специально для спецификации WS-Security, это одна хорошая спецификация, и если кто-то, думая в Enterprise JSON, определенно должен прийти с чем-то похожим на JSON, например, на шифрование на уровне поля и т. д.


Если вы ищете возможность взаимодействия между различными системами и языками, я бы определенно пошел на REST. У меня было много проблем с попыткой заставить SOAP работать между .NET и Java, например.


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


Один быстрый протокол передачи и оркестровка;

Я использую SOAP через TCP для обеспечения скорости, надежности и безопасности, включая организованные машины для машинных служб (ESB) и внешние службы. Измените определение службы, оркестровка вызывает ошибку из-за изменения WSDL и ее сразу видно и может быть перестроена / развернута.

Не уверен, что вы можете сделать то же самое с REST - я жду исправления или курса! С помощью REST измените определение сервиса - ничего не известно об этом, пока оно не вернет 400 (или что-то еще).


Отвечая на вопрос, освещенный в 2012 году (по второму вопросу), и обзор сегодняшних результатов (другие ответы).

SOAP, плюсы и минусы

О SOAP 1.2, преимуществах и недостатках при сравнении с «REST» ... Ну, с 2007 года вы можете описывать веб-службы REST с помощью WSDL и использовать протокол SOAP ... То есть, если вы работаете немного сложнее, все стандарты W3C стек протоколов веб-сервисов может быть REST !

Это хорошая отправная точка, потому что мы можем представить сценарий, в котором все философские и методологические обсуждения временно устраняются. Мы можем сравнить технически «SOAP-REST» с «NON-SOAP-REST» в аналогичных сервисах,

  • SOAP-REST (= «REST-SOAP»): как показал Л. Мандель , WSDL2 может описывать веб- службу REST, и, если мы предположим, что примерный XML может быть окутан SOAP, вся реализация будет «SOAP-REST», ,

  • NON-SOAP-REST : любая веб-служба REST, которая не может быть SOAP ... То есть «90%» хорошо известных REST-примеров. Некоторые не используют XML (например, типичные AJAX REST используют JSON вместо), некоторые используют другие XML-структуры, без заголовков или правил SOAP. PS: чтобы избежать неформальности, мы можем предположить, что martinfowler.com/articles/richardsonMaturityModel.html в сравнении.

Разумеется, для сравнения более концептуально сравните «NON-REST-SOAP» с «NON-SOAP-REST», как различные подходы к моделированию. Итак, завершая эту таксономию веб-сервисов:

  • NON-REST-SOAP : любая веб-служба SOAP, которая не может быть REST ... То есть «90%» хорошо знакомых примеров SOAP.

  • NON-REST-NEITHER-SOAP : да, вселенная «моделирования веб-сервисов» включает в себя другие вещи (например, XML-RPC ).

SOAP в условиях REST

Сравнение сопоставимых вещей: SOAP-REST с NON-SOAP-REST .

ПРОФИ

Объясняя некоторые термины,

  • Контрактная стабильность : для всех видов контрактов (как «письменные соглашения»)

    • С помощью стандартных : все уровни стека W3C совместимы друг с другом . REST, с другой стороны, не является стандартом W3C или ISO и не имеет нормализованных данных о периферийных устройствах службы. Итак, как I , @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), упомянутых ранее, в контексте, где НУЖДЕН ДЛЯ СТАНДАРТОВ, вам нужен SOAP.

    • Используя лучшие практики : «подробный аспект» реализаций стека W3C , переводит соответствующие человеческие / юридические / юридические соглашения.

  • Надежность : безопасность структуры SOAP и заголовков. С коммуникацией metada (с полной выразительностью XML) и verification вас есть «страховой полис» от любых изменений или шумов.
    SOAP имеет «надежность транзакций» (...) в отношении сбоев связи. SOAP имеет больше возможностей для контроля логики повтора и, таким образом, может предоставлять дополнительные сквозные гарантии надежности и обслуживания », E. Terman .

Сортировка профи по популярности,

  • Лучшие инструменты (~ 70 голосов): SOAP в настоящее время имеет преимущество с лучшими инструментами, начиная с 2007 года и еще до 2012 года, потому что это хорошо определенный и общепринятый стандарт. См. @MarkCidade (27 голосов), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

  • Соответствие стандартам (25 голосов): как I , @DaveWoldrich (20 голосов), @cynicalman (5), @Exitos (0), упомянутых ранее, в контексте, где НУЖДЕН ДЛЯ СТАНДАРТОВ, вам нужен SOAP.

  • Надежность : страхование заголовков SOAP, @JohnSaunders (8 голосов).

МИНУСЫ

  • Структура SOAP более сложная (более 300 голосов): все ответы здесь, а источники о «SOAP vs REST» проявляют некоторую степень неприязни к избыточности и сложности SOAP. Это является естественным следствием требований к формальной проверке (см. Ниже) и надежности (см. Выше). «REST NON-SOAP» (и XML-RPC, создатель SOAP ) может быть более простым и неформальным.

  • Ограничение «только XML» является препятствием производительности при использовании крошечных сервисов (~ 50 голосов): см. json.org/xml и этот вопрос , или этот другой . Этот момент проявляется @toluju (41) и другими.
    PS: поскольку JSON не является стандартом IETF , но мы можем рассматривать де-факто стандарт для сообщества веб-программного обеспечения.

Услуги моделирования с помощью SOAP

Теперь мы можем добавить SOAP-NON-REST с сравнениями NON-SOAP-REST и объяснить, когда лучше использовать SOAP :

  • Необходимость стандартов и стабильных контрактов (см. Раздел «PROS»). PS: см. Типичную «потребность в B2B для стандартов», описанную @saille .

  • Необходимость в инструментах (см. Раздел «PROS»). PS: стандарты и наличие формальных проверок (см. Ниже) являются важными проблемами для автоматизации инструментов.

  • Параллельная интенсивная обработка (см. Ниже раздел «Контекст / Основы»): при больших и / или более медленных процессах, несмотря на немного сложность SOAP, надежность и стабильность - лучшие инвестиции.

  • Требуется больше безопасности : когда требуется больше HTTPS, и вам действительно нужны дополнительные функции для защиты, SOAP - лучший выбор ( см. @Bell , 32 голоса). «Отправка сообщения по пути, более сложному, чем запрос / ответ или транспорт, который не связан с HTTP», S. Seely . XML является основной проблемой, предлагая стандарты для шифрования XML, подписи XML и канонизации XML , и только с помощью SOAP вы можете внедрить эти механизмы в сообщение по хорошо принятому стандарту WS-Security .

  • Требуется больше гибкости (меньше ограничений): SOAP не нуждается в точном соответствии с URI; not nedd ограничивает HTTP; не нужно ограничивать до 4 глаголов. Как сказал @TravisHeseman (9 голосов), если вы хотите что-то «гибкое для произвольного количества клиентских технологий и использования», используйте SOAP.
    PS: помните, что XML является более универсальным / выразительным, чем JSON (и др.).

  • Необходимость verification : важно понимать, что стек W3C использует формальные методы , а REST более неформальный. Описание службы WSDL ( официальный язык ) - это формальная спецификация интерфейсов ваших веб-сервисов, а SOAP - надежный протокол, который принимает все возможные рецепты WSDL.

КОНТЕКСТ

исторический

Для оценки тенденций необходима историческая перспектива. По этому вопросу, перспектива 10 или 15 лет ...

До стандартизации W3C существует некоторая анархия. Было сложно реализовать совместимые сервисы с различными структурами, а также более сложные, дорогостоящие и трудоемкие для реализации чего-то совместимого между компаниями. Стандарты стека W3C были легкими, а север - для взаимодействия наборов сложных веб-сервисов.

Для повседневных задач, как и для реализации AJAX, SOAP тяжелый ... Итак, необходимость простых подходов должна выбрать новую теорию-структуру ... И большие «игроки веб-программного обеспечения», как Google, Amazon, Yahoo и др. Выбрали лучшую альтернативу, то есть подход REST. В этом контексте концепция REST появилась как «конкурирующая структура», и сегодня (2012 год) эта альтернатива является стандартом де-факто для программистов.

устои

В контексте параллельных вычислений веб-службы предоставляют параллельные подзадачи; и протоколы, такие как SOAP, обеспечивают хорошую синхронизацию и связь. Не «любая задача»: веб-сервисы можно классифицировать как
грубый и смущающий параллелизм .

По мере того как задача становится больше, она становится менее значимой «дискуссией по сложности» и становится более актуальной в отношении надежности сообщения и надежности контрактов.


Слушайте этот подкаст, чтобы узнать. Если вы хотите узнать ответ без прослушивания, то ОК, его ОТДЫХ. Но я действительно рекомендую слушать.


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

Мне любопытно, что думают другие.


Я бы порекомендовал вам сначала запустить REST - если вы используете Java, посмотрите на JAX-RS и реализацию Jersey . REST намного проще и легко взаимодействует на многих языках.

Как отмечали другие пользователи в этой теме, проблема с SOAP связана с его сложностью при появлении других спецификаций WS- * и возникают бесчисленные проблемы взаимодействия, если вы попадаете в неправильные части WSDL, XSD, SOAP, WS-Addressing и т. Д.

Лучший способ оценить дискуссию REST v SOAP - это смотреть в Интернете - почти все крупные игроки в веб-пространстве, google, amazon, ebay, twitter и др. - склонны использовать и предпочитают API RESTful поверх SOAP.

Другим приятным подходом к работе с REST является то, что вы можете повторно использовать много кода и инфраструктуру между веб-приложением и интерфейсом REST. например, рендеринг HTML и XML по сравнению с JSON ваших ресурсов, как правило, довольно прост в таких фреймворках, как JAX-RS и неявные представления, плюс его простота работы с ресурсами RESTful с помощью веб-браузера


Я знаю, что это старый вопрос, но я должен опубликовать свой ответ - может быть, кто-то найдет его полезным. Я не могу поверить, сколько людей рекомендуют REST над SOAP. Я могу только предположить, что эти люди не являются разработчиками или никогда не реализовывали сервис REST любого разумного размера. Реализация службы REST занимает LOT дольше, чем реализация SOAP-сервиса. И, в конце концов, это тоже намного грязнее. Вот причины, по которым я бы выбрал SOAP 99% времени:

1) Внедрение службы REST длится бесконечно дольше, чем реализация SOAP-сервиса. Инструменты существуют для всех современных языков / фреймворков / платформ для чтения в WSDL и вывода классов и клиентов прокси. Внедрение службы REST выполняется вручную, и - получите это - путем чтения документации. Кроме того, при реализации этих двух сервисов вы должны делать «догадки» относительно того, что будет возвращаться через трубу, поскольку нет реальной схемы или справочного документа.

2) Зачем писать службу REST, которая в любом случае возвращает XML? Единственное различие заключается в том, что с помощью REST вы не знаете типы, которые представляет каждый элемент / атрибут, - вы сами по себе, чтобы реализовать его, и надеетесь, что в один прекрасный день строка не встретится в поле, которое, по вашему мнению, всегда было int. SOAP определяет структуру данных, используя WSDL, поэтому это не требует больших усилий.

3) Я слышал жалобу, что с SOAP у вас есть «накладные расходы» в конверте SOAP. В этот день и возраст, действительно ли нам нужно беспокоиться о нескольких байтах?

4) Я слышал аргумент, что с помощью REST вы можете просто поместить URL-адрес в браузер и посмотреть данные. Конечно, если ваша служба REST использует простую или не аутентификацию. Например, служба Netflix использует OAuth, которая требует, чтобы вы подписали вещи и закодировали вещи, прежде чем вы сможете даже отправить свой запрос.

5) Зачем нам нужен «читаемый» URL для каждого ресурса? Если мы использовали инструмент для реализации службы, действительно ли мы заботимся о фактическом URL?

Нужно ли продолжать?


Я построил один из первых SOAP-серверов, включая генерацию кода и генерации WSDL, из первоначальной спецификации, когда он разрабатывался, когда я работал в Hewlett-Packard. Я НЕ рекомендую использовать SOAP для чего-либо.

Акроним «SOAP» - ложь. Это не просто, он не Object-oriented, он не определяет правила доступа. Это, возможно, Протокол. Это худшая специфика Дона Бокса, и это довольно подвиг, так как он - человек, который совершил «СОМ».

В SOAP нет ничего полезного, что нельзя сделать с помощью REST для транспорта, JSON, XML или даже обычного текста для представления данных. Для безопасности транспорта вы можете использовать https. Для аутентификации, базовый auth. Для сеансов есть файлы cookie. Версия REST будет проще, понятнее, быстрее работать и использовать меньшую пропускную способность.

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


Я смотрю на то же самое, и я думаю, что это разные инструменты для разных задач .

Стандарт простого доступа к объектам (SOAP) - язык XML, определяющий архитектуру сообщений и форматы сообщений, используется веб-службами, содержащими описание операций. WSDL - это язык, основанный на XML, для описания веб-сервисов и способов доступа к ним. будет работать на SMTP, HTTP, FTP и т. д. Требуется поддержка промежуточного программного обеспечения, четко определенный механизм для определения таких сервисов, как WSDL + XSD, WS-Policy SOAP вернет данные на основе XML. SOAP обеспечивает стандарты безопасности и надежности

Репрезентативные переводы государственных услуг (RESTful). это веб-службы второго поколения. Веб-службы RESTful, обмениваются данными через HTTP, чем службы на основе SOAP, и не требуют XML-сообщений или определений WSDL-сервиса-API. для REST не требуется промежуточное ПО, требуется только поддержка HTTP. Стандарт WADL, REST может возвращать XML, обычный текст, JSON, HTML и т. д.

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

  1. REST использует стандартный HTTP, поэтому он упрощает создание клиентов, разрабатывая API
  2. REST позволяет использовать много разных форматов данных, таких как XML, обычный текст, JSON, HTML, где SOAP разрешает только XML.
  3. REST имеет лучшую производительность и масштабируемость.
  4. Отдых и может быть кэширован, а SOAP не может
  5. Встроенная обработка ошибок, в которых SOAP отсутствует Обработка ошибок
  6. REST - особенно полезный КПК и другие мобильные устройства.

REST - это услуги, которые легко интегрировать с существующими веб-сайтами.

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

Для SOAP сложного API будет более полезным.


Я уверен, что Don Box создал SOAP в качестве шутки - «посмотрите, что вы можете вызвать RPC-методы через Интернет», и сегодня стонет, когда он осознает, что раздутый кошмар веб-стандартов стал :-)

REST хорош, прост, реализован везде (так более «стандарт», чем стандарты) быстро и легко. Используйте REST.


В настоящее время SOAP имеет преимущество в лучших инструментах, в которых они будут генерировать много шаблонов кода для уровня обслуживания, а также для генерации клиентов из любого данного WSDL.

REST упрощается, может быть легче поддерживать в результате, лежит в основе веб-архитектуры, позволяет лучше видеть протокол и, как оказалось, масштабируется по размеру самой WWW. Некоторые фреймворки помогают вам создавать службы REST, такие как Ruby on Rails, а некоторые даже помогают вам писать клиентов, например ADO.NET Data Services. Но по большей части поддержка инструмента отсутствует.


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

Моя работа включает в себя разработку и разработку решений IoT (Internet of Things). К ним относится разработка кода для небольших встроенных устройств, которые взаимодействуют с облаком.

Ясно, что REST теперь широко признан и полезен, и в значительной степени стандарт defacto для Интернета, даже Microsoft имеет поддержку REST, включенную в Azure. Если бы мне нужно было полагаться на SOAP, я не мог бы делать то, что мне нужно, просто слишком большой, громоздкий и раздражающий для небольших встроенных устройств.

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


Я создаю бенчмарк, чтобы найти, какие из них быстрее! я вижу этот результат:

для 1000 запросов:

  • REST занял 3 секунды
  • SOAP занял 7 секунд

для 10 000 запросов:

  • REST занял 33 секунды
  • SOAP занял 69 секунд

за 1 000 000 запросов:

  • REST занял 62 секунды
  • SOAP занял 114 секунды




soap