SOAP vs REST (различия)

REST vs SOAP is не правильная постановка вопроса.

REST в отличие от SOAP is не протокол.

REST Это архитектурный стиль и конструкция для сетевых программных архитектур.

REST понятия называются ресурсами. Представление ресурса должно быть без гражданства. Она представлена через некоторые СМИ тип. Некоторые примеры типов носителей включают XML, JSON и RDF. Ресурсы управляются компонентами. Компоненты запрашивают и управляют ресурсами через стандартный единообразный интерфейс. В случае HTTP этот интерфейс состоит из стандартных http ops, например GET, PUT, POST, DELETE.

@Абдулазиз вопрос не осветить тот факт, что REST и HTTP часто используются в тандеме. Это в первую очередь связано с простотой HTTP и его очень естественным сопоставление с принципами RESTful.

основные принципы отдыха

Связь Клиент-Сервер

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

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

Cacheable

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

Единый Интерфейс

все компоненты должны взаимодействовать через единый унифицированный интерфейс. Поскольку все взаимодействие компонентов происходит через этот интерфейс, взаимодействие с различными службами очень просто. Интерфейс тот же самый! Это также означает, что изменения в реализации могут вноситься изолированно. Такие изменения не повлияют на взаимодействие фундаментальных компонентов, поскольку единый интерфейс всегда остается неизменным. Одним из недостатков является то, что вы застряли с интерфейсом. Если оптимизация может быть предоставлена конкретному сервис, изменив интерфейс, вам не повезло, так как отдых запрещает это. С другой стороны, REST оптимизирован для интернета, поэтому невероятная популярность REST по HTTP!

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

посмотреть этот блог в должности on остальные принципы проектирования подробнее о остальное и вышеуказанные патроны.

EDIT: обновление контента на основе комментариев

мыло (Простой Протокол Доступа К Объектам) и остальные (Представление Государственной Передачи) оба по-своему красивы. Поэтому я не сравниваю их. Вместо этого я пытаюсь изобразить картину, когда я предпочитал использовать отдых и когда мыло.

что такое полезная нагрузка?

когда данные отправляются через Интернет, каждый передаваемый блок включает в себя как информацию заголовка, так и фактические отправляемые данные. Заголовок определяет источник и назначение пакета,в то время как фактические данные называются полезной нагрузкой. Как правило, полезная нагрузка - это данные, которые передаются от имени приложения, и данные, полученные целевой системой.

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

так скажите мне среди ниже упомянутых этих двух сообщений, какое из них дешевле отправить?

<name>Arin</name>

или

"name": "Arin"

Я знаю, что ваш ответ будет второй, хотя оба представляют одно и то же сообщение второй дешевле по стоимости.

поэтому я пытаюсь сказать, что,отправка данных по сети в формате JSON дешевле, чем отправка в формате XML относительно полезной нагрузки.

вот первое преимущество или преимущества отдыха над мылом. SOAP поддерживает только XML, но REST поддерживает различный формат как текст, JSON, XML, etc. И мы уже знаем, если мы используем Json, то определенно мы будем в лучшем месте относительно полезной нагрузки.

теперь SOAP поддерживает только XML,но она также имеет свои преимущества.

действительно! Как?

SOAP полагается на XML тремя способами Конверт-это определяет, что находится в сообщении и как его обрабатывать.

набор правил кодирования для типов данных, и, наконец, макет процедура звонков и ответов собрана.

этот конверт отправляется через транспорт (HTTP / HTTPS), и выполняется RPC (удаленный вызов процедуры), и конверт возвращается с информацией в XML-форматированном документе.

важным моментом является то, что одно из преимуществ мыла использование "общие" транспорта но REST использует HTTP / HTTPS. SOAP может использовать практически любой транспорт для отправки запроса, но REST не может. Так здесь мы получили преимущество использования мыла.

Как я уже упоминал в предыдущем пункте "REST использует HTTP / HTTPS", так что идите немного глубже на эти слова.

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

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

кроме того, как REST ограничен протоколом HTTP таким образом, поддержка транзакций не совместима с ACID и не может обеспечить двухфазную фиксацию распределенных транснациональных ресурсов.

но мыло имеет всестороннюю поддержку для обоих ACID на основе управления транзакциями для краткосрочных транзакций и транзакций на основе компенсации управление долгосрочными транзакциями. Он также поддерживает двухфазная фиксация по распределенным ресурсам.

Я не делаю никаких выводов, но я предпочту веб-службу на основе SOAP во время безопасности, транзакций и т. д. основными проблемами.

вот" учебник Java EE 6", где они сказали дизайн RESTful может быть соотвествующим когда следующие условия соотвествованы. Взглянуть.

Надеюсь, вам понравилось прочитав мой ответ.

остальное(REпредставления SТэйт Tтрансфер)
Отдых-это архитектурный стиль. Он не определяет так много стандартов, как мыло. REST предназначен для предоставления общедоступных API(например, Facebook API, Google Maps API) через интернет для обработки операций CRUD с данными. Отдых ориентирован на доступ к именованным ресурсам через единый унифицированный интерфейс.

мыло(SРеа Object Access Protocol)
SOAP приносит свой собственный протокол и фокусируется на предоставлении частей логики приложения (а не данных) в качестве служб. SOAP предоставляет операции. SOAP ориентирован на доступ к именованным операциям, каждая операция реализует некоторую бизнес-логику. Хотя мыло обычно называют веб-служб это неправильно. Мыло имеет очень мало общего с сетью. Отдых обеспечивает true веб-служб на основе URIs и HTTP.

зачем отдыхать?

• поскольку REST использует стандартный HTTP, это намного проще почти всегда.
• REST легче реализовать, требует меньше пропускной способности и ресурсов.
• REST разрешает множество различных форматов данных, где AS SOAP разрешает только XML.
• REST обеспечивает лучшую поддержку клиентов браузера благодаря поддержке JSON.
• REST имеет лучшую производительность и масштабируемость. ОСТАЛЬНОЕ чтения могут быть кэшированы, чтения на основе SOAP не могут быть кэшированы.
• если безопасность не является серьезной проблемой, и у нас есть ограниченные ресурсы. Или мы хотим создать API, который будет легко использоваться другими разработчиками публично, тогда мы должны пойти с REST.
• если нам нужны операции без гражданства, то идите с отдыхом.
• REST обычно используется в социальных сетях, веб-чате, мобильных сервисах и общедоступных API, таких как Google Maps.
• RESTful сервис возврата различных MediaTypes для того же ресурса, в зависимости от параметра заголовка запроса "Accept" as application/xml или application/json для POST и /user/1234.json или GET /user/1234.xml для GET.
• службы REST должны вызываться клиентским приложением, а не конечным пользователем напрямую.
• ST в остальных исходит от SТэйт Tтрансфер. Вы переносите состояние вокруг вместо того, чтобы хранить его на сервере, это делает службы REST масштабируемыми.

почему мыло?

• SOAP не очень легко реализовать и требует больше пропускной способности и ресурсов.
• запрос сообщения SOAP обрабатывается медленнее по сравнению с REST и не использует механизм веб-кэширования.
• WS-Security: хотя SOAP поддерживает SSL (как и REST), он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия.
• WS-AtomicTransaction: нужны кислотные транзакции через службу, вам понадобится мыло.
• WS-ReliableMessaging: если вашему приложению требуется асинхронная обработка и гарантированный уровень надежности и безопасности. Rest не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут иметь дело с сбоями связи путем повторной попытки.
• если безопасность является серьезной проблемой и ресурсы не ограничены, то мы следует использовать веб-службы SOAP. Например, если мы создаем веб-сервис для платежных шлюзов, финансовой и телекоммуникационной работы, мы должны пойти с SOAP, поскольку здесь требуется высокая безопасность.

файлы source1
файл source2

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

остальные принципы

• все в REST рассматривается как ресурс.
• каждый ресурс идентифицируется URI.
• использует унифицированные интерфейсы. Ресурсы обрабатываются с помощью операций POST, GET, PUT, DELETE, аналогичных операциям Create, Read, Update и Delete (CRUD).
• быть без гражданства. Каждый запрос является независимым запросом. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса.
• связь осуществляется через представления. Е. Г., XML и веб-служб RESTful json-файле. Веб-службы RESTful основаны на HTTP-методах и концепции REST. RESTful веб служба обычно определяет базовый URI для служб; поддерживаемые типы MIME (XML, text, JSON, user-defined, ...) и набор операций (POST, GET, PUT, DELETE), которые поддерживаются.

мыльные основы

• WSDL определяет контракт между клиентом и сервисом и является статичным по своей природе.
• SOAP создает протокол на основе XML поверх HTTP или иногда TCP / IP.
• SOAP описывает функции и типы данные.
• SOAP является преемником XML-RPC и очень похож, но описывает стандартный способ общения.
• несколько языков программирования имеют встроенную поддержку SOAP, вы обычно кормите его URL веб-службы, и вы можете вызвать его функции веб-службы без необходимости конкретного кода.
• двоичные данные, которые передаются, должны быть закодированы в формате base64 закодированный.
• имеет несколько протоколов и технологий, связанных с ним: WSDL, XSD, SOAP, WS-адресация.

мыло против отдыха?

одним из основных преимуществ SOAP является то, что у вас есть описание службы WSDL. Вы можете в значительной степени обнаружить службу автоматически и генерировать полезный прокси-сервер клиента из этого описания службы (генерировать вызовы службы, необходимые типы данных для методов и т. д.). Обратите внимание, что в версии 2.0 WSDL поддерживает все команды HTTP и может использоваться для документирования служб RESTful, но для этой цели в WADL (язык описания веб-приложений) существует менее подробная альтернатива.

с RESTful services, безопасность сообщений обеспечивается транспортным протоколом (HTTPS) и только точка-точка. Он не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут иметь дело с сбоями связи путем повторной попытки. SOAP имеет встроенную логику успешных/повторных попыток и обеспечивает сквозную надежность даже через посредников SOAP.

одно из главных преимуществ API RESTful является гибким для представления данных, например, вы можете сериализовать свои данные в формате XML или JSON. RESTful API чище или проще понять, потому что они добавляют элемент использования стандартизированных URI и придают важность используемому http-глаголу (т. е. GET, POST, PUT и DELETE).

RESTful услуги также легкий, то есть они не имеют много дополнительной разметки XML. Для вызова RESTful API все, что вам нужно, это браузер или стек HTTP и в значительной степени это есть на каждом устройстве или машине, подключенной к сети.

преимущества отдыха

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

преимущества мыла

• WS-Security: хотя SOAP поддерживает SSL (как и REST), он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия. Поддерживает идентичность через посредники, а не просто точка-точка (SSL). Он также обеспечивает стандартную реализацию целостности данных и конфиденциальности данных. Называя его "предприятием", нельзя сказать, что он более безопасен, он просто поддерживает некоторые инструменты безопасности, которые типичным интернет-сервисам не нужны, на самом деле они нужны только в нескольких сценариях" предприятия".
• WS-AtomicTransaction: нужны кислотные транзакции через службу, вам понадобится мыло. Хотя REST поддерживает транзакции, это не так всесторонне и не КИСЛОВОЧНО уступчиво. К счастью, кислотные транзакции почти никогда не имеют смысла через интернет. REST ограничен самим HTTP, который не может обеспечить двухфазную фиксацию через распределенные транзакционные ресурсы, но SOAP может. Интернет-приложениям не нужен этот уровень транзакционной надежности, иногда это делают корпоративные приложения.
• WS-ReliableMessaging: Rest не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут иметь дело с сбоями связи повторение. SOAP имеет встроенную логику успешных/повторных попыток и обеспечивает сквозную надежность даже через посредников SOAP.
• язык, платформа и транспорт независимы (REST требует использования HTTP)
• хорошо работает в распределенных корпоративных средах (REST предполагает прямую связь точка-точка)
• стандартизированные
• обеспечивает значительную расширяемость предварительной сборки в виде стандартов WS
• встроенная ошибка обработка
• автоматизация при использовании с некоторыми языковыми продуктами

где использовать REST

области, где отдых хорошо работает для:

• ограниченная пропускная способность и ресурсы: помните, что структура возврата действительно в любом формате (определяется разработчиком). Кроме того, любой браузер можно использовать, потому что подход REST использует стандартные глаголы GET, PUT, POST и DELETE. Опять же, помните, что REST также может использовать XMLHttpRequest объект, который большинство современных браузеров поддерживают сегодня, что добавляет бонус AJAX.
• операции без гражданства: если операция должна быть продолжена, то отдых-не лучший подход, и SOAP может соответствовать ему лучше. Однако, если вам нужны операции без состояния CRUD (Create, Read, Update и Delete), то REST-это он.
• кэширование ситуациях: если информация может быть кэширована из - за операции без состояния подхода REST, это идеальный.

где использовать мыло

области, где мыло работает как отличное решение:

• асинхронная обработка и вызов: если вашему приложению требуется гарантированный уровень надежности и безопасности, SOAP 1.2 предлагает дополнительные стандарты для обеспечения такого типа работы. Такие вещи, как Wsrm-WS-надежные сообщения.
• официальные договоры: если обе стороны (поставщик и потребитель) имеют чтобы договориться о формате обмена, SOAP 1.2 дает жесткие спецификации для этого типа взаимодействия.
• операции с состоянием: если приложение нуждается в контекстной информации и разговорном управлении состоянием, то SOAP 1.2 имеет дополнительную спецификацию в структуре WS для поддержки этих вещей (безопасность, транзакции, координация и т. д.). Сравнительно, остальной подход заставил бы разработчиков построить эту пользовательскую сантехнику.

разница между отдыхом и мылом

мыло

1. SOAP-это протокол.
2. SOAP означает простой протокол доступа к объектам.
3. SOAP не может использовать REST, потому что это протокол.
4. SOAP использует интерфейсы служб для предоставления бизнес-логики.
5. SOAP определяет стандарты, которые должны строго соблюдаться.
6. SOAP требует больше пропускной способности и ресурсов, чем REST.
7. SOAP определяет свой собственный безопасность.
8. SOAP разрешает только формат XML-данных.
9. мыло менее предпочтительно, чем отдых.

остальное

1. REST-это архитектурный стиль.
2. REST означает передачу репрезентативного состояния.
3. REST может использовать веб-службы SOAP, потому что это концепция и может использовать любой протокол, такой как HTTP, SOAP.
4. REST использует URI для раскрытия бизнес-логики.
5. REST не определяет слишком много стандарты как мыло.
6. REST требует меньше пропускной способности и ресурсов, чем SOAP.
7. RESTful web services наследует меры безопасности от базового транспорта.
8. REST разрешает различный формат данных, такой как обычный текст, HTML, XML, JSON и т. д.
9. отдых более предпочтителен, чем мыло.

Подробнее см. здесь

IMHO вы не можете сравнить мыло и отдых, где это две разные вещи.

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

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

остальное представляет состояние (как ресурсы) сервера из URL-адреса.Он не имеет состояния, и клиенты не должны иметь предварительных знаний для взаимодействия с сервером за пределами понимания гипермедиа.

дополнение:

++ ошибка, часто совершаемая при приближении к REST, заключается в том, чтобы думать об этом как о "веб-службах с URL-адресами" - думать о REST как о другом механизме удаленного вызова процедур (RPC), таком как SOAP, но вызываемом через простые URL-адреса HTTP и без здоровенных пространств имен XML SOAP.

++ напротив, REST имеет мало общего с RPC. В то время как RPC ориентирован на обслуживание и ориентирован на действия и глаголы, REST ориентирован на ресурсы, подчеркивая вещи и существительные, которые включают в себя приложения.

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

многие из этих ответов полностью забыли упомянуть элементы управления гипермедиа (HATEOAS), которые полностью фундаментальны для отдыха. Несколько других коснулись этого, но не очень хорошо объяснили.

в этой статье следует объяснить разницу между понятиями, не попадая в сорняки на конкретных особенностях мыла.

• SOAP-это протокол, тогда как REST-это архитектура.
• SOAP предоставляет поведение, которое представляет логику, тогда как REST предоставляет ресурсы, которые представляют данные.
• С точки зрения потребления отдых сервис намного проще, чем мыло. С остальными накладными расходами обработки XML-конвертов устраняется, что делает его более быстрым по сравнению с SOAP.
• мыло обеспечило хорошие варианты безопасности по сравнению с ОСТАЛЬНОЕ.
• для взаимодействия машины с машиной и корпоративных решений SOAP предпочтительнее, но для общедоступного API REST-лучший вариант почти 70% общедоступных API-это REST.
• остальные облегченны, ремонтопригодны & масштабируемы.
• REST не зависит от устройства, т. е. клиент, потребляющий REST API, может быть чем угодно, например, мобильными устройствами, ноутбуками, телевизором и т. д.
• с облаком приходит в действие. Приложение медленно перемещается в облачные системы, такие как Azure, Amazon АРМ. Эти системы строят и предоставляют REST API. Следовательно, это хороший шаг для создания приложения поверх REST API.

отдых против мыла

прежде всего: в широком смысле,веб-сервиса означает использование протокола HTTP для передачи сведения вместо веб-страниц. Однако, в строгом смысле веб-сервиса как определено W3C - это очень специфическая форма этой идеи. Итак, когда люди говорят о мыло против отдыха, они на самом деле означают веб-службы против REST (где "веб-службы" относятся к официальному определению, поскольку на практике службы REST также называются веб-сервисы всеми).

Итак, предположим, вы хотите вызвать функцию на удаленном компьютере, реализованную на другом языке программирования (удаленный вызов процедуры / RPC). Вы должны (как-то) отправить ему сообщение и получить какой-то ответ. Во-первых, эту функцию можно найти по определенному URL-адресу, предоставленному ее создателем. Затем следует рассмотреть два основных вопроса.

• каков формат сообщения, которое вы должны отправить
• как сообщение должно передаваться взад и вперед

согласно официальному определению, ответом на первый вопрос является WSDL-файл, XML, который описывает в подробном и строгом формате, каковы параметры, каковы их типы, имена, значения по умолчанию, имя вызываемой функции и т. д. На второй вопрос есть разные ответы. Самым популярным (на сегодняшний день) является мыло. Его основная идея: wrap предыдущий XML (фактическое сообщение) в еще один XML и отправить его по HTTP (хотя, теоретически, он может быть использован с другими протоколами, но никто никогда не делает этого). Метод POST HTTP используется для отправки сообщения, так как всегда есть тело.

Итак, по подходу (широко, но ошибочно), называемому SOAP, вы сопоставляете URL-адрес функции, то есть действие. The спокойный подход: вместо URL, представляющего действие, он должен представлять вещь (под названием ресурс на спокойном жаргоне). Поскольку протокол HTTP (который мы уже используем) поддерживает глаголы, используйте эти глаголы, чтобы указать, какие действия выполнять над вещью.

Итак, с подходом SOAP (опять же, неправильный термин), если у вас есть список клиентов, и вы хотите просмотреть/обновить/удалить один, у вас будет 3 url:

• myapp/read-customer и в теле сообщения, передайте ИД клиента для того чтобы быть читать.
• myapp/update-customer и в теле, передать идентификатор клиента, а также новые данные
• myapp/delete-customer и идентификатор в теле

в то время как, с остальным подходом, у вас будет только myapp/customers/3 (где 3 - идентификатор конкретного клиента). Чтобы просмотреть данные клиента, нажмите URL-адрес с запросом GET. Чтобы удалить его, тот же URL, с глаголом удаления. Чтобы обновить его, опять же URL с глаголом POST и новое содержимое в теле запроса.

для получения более подробной информации о требованиях, которые служба должна выполнять, чтобы считаться действительно RESTful, см. модель зрелости Ричардсона. В статье приводятся примеры и, что еще более важно, объясняется, почему (так называемый) SOAP-сервис, является сервисом REST уровня 0 (хотя, уровень 0 означает низкое соответствие этой модели, это не оскорбительно, и это все еще полезно во многих случаях).