Я читал статьи о различиях между SOAP и REST как протоколом связи веб-службы, но я думаю, что самые большие преимущества для REST по сравнению с SOAP:
REST более динамичен, нет необходимости создавать и обновлять UDDI (универсальное описание, обнаружение и интеграция).
REST не ограничивается только форматом XML. Веб-сервисы RESTful могут отправлять обычный текст /JSON/XML.
Но SOAP более стандартизирован (например, безопасность).
Итак, я прав в этих пунктах?
К сожалению, в REST существует много дезинформации и неправильных представлений. Не только ваш вопрос и ответ @cmd отражают их, но большинство вопросов и ответов, связанных с предметом в Stack Overflow.
SOAP и REST нельзя сравнивать напрямую, так как первый - это протокол (или, по крайней мере, пытается быть), а второй - архитектурный. Вероятно, это один из источников беспорядка вокруг него, поскольку люди обычно называют REST любым HTTP-API, который не является SOAP.
Немного продвигая вещи и пытаясь установить сравнение, основное различие между SOAP и REST - это степень взаимодействия между реализациями клиента и сервера. Клиент SOAP работает как пользовательское настольное приложение, тесно связанное с сервером. Там жесткий контракт между клиентом и сервером, и все, как ожидается, сломается, если какая-либо сторона что-то изменит. После любых изменений вам понадобятся постоянные обновления, но легче выяснить, соблюдается ли контракт.
Клиент REST больше похож на браузер. Это общий клиент, который знает, как использовать протокол и стандартизованные методы, и приложение должно соответствовать этому. Вы не нарушаете стандарты протокола, создавая дополнительные методы, вы используете стандартные методы и создаете с ними действия по типу вашего медиа. Если все сделано правильно, там меньше связей, и изменения могут быть обработаны более изящно. Предполагается, что клиент должен войти в службу REST с нулевым знанием API, за исключением точки входа и типа носителя. В SOAP клиенту нужны предыдущие знания обо всем, что он будет использовать, или он даже не начнет взаимодействие. Кроме того, клиент REST может быть расширен кодом по требованию, предоставленным самим сервером, классическим примером является код JavaScript, используемый для управления взаимодействием с другой службой на стороне клиента.
Я думаю, что это решающие моменты, чтобы понять, что такое REST, и как он отличается от SOAP:
REST не зависит от протокола. Он не связан с HTTP. В значительной степени, как вы можете следить за ftp-ссылкой на веб-сайте, приложение REST может использовать любой протокол, для которого существует стандартизованная схема URI.
REST не является отображением методов CRUD to HTTP. Прочтите этот ответ для подробного объяснения этого.
REST стандартизирован как части, которые вы используете. Безопасность и аутентификация в HTTP стандартизованы, так что вы используете при выполнении REST через HTTP.
REST не является REST без гипермедиа и HATEOAS. Это означает, что клиент знает только URI точки входа, и ресурсы должны возвращать ссылки, которым должен следовать клиент. Эти причудливые генераторы документации, которые предоставляют шаблоны URI для всего, что вы можете сделать в REST API, полностью упускают из виду. Они не только документируют то, что должно соответствовать стандарту, но когда вы это делаете, вы связываете клиента с одним конкретным моментом в эволюции API, и любые изменения в API должны быть документированы и применены, или он сломается.
REST - это архитектурный стиль самого веб-сайта. Когда вы вводите Stack Overflow, вы знаете, что такое Пользователь, вопрос и ответ, вы знаете типы медиа, и веб-сайт предоставляет вам ссылки на них. API REST должен сделать то же самое. Если мы разработали Интернет так, как люди должны думать, что REST должен быть сделан, вместо того, чтобы иметь домашнюю страницу со ссылками на вопросы и ответы, у нас была бы статическая документация, объясняющая, что для просмотра вопроса вам нужно взять URI stackoverflow.com/questions/<id>, замените id на Question.id и вставьте его в свой браузер. Это глупость, но то, что многие считают REST.
Эта последняя точка не может быть подчеркнута достаточно. Если ваши клиенты строят URI из шаблонов в документации и не получают ссылок в представлениях ресурсов, это не REST. Рой Филдинг, автор REST, дал понять это сообщение в блоге: API REST должен быть основан на гипертексте.
С учетом вышеизложенного вы поймете, что, хотя REST может не ограничиваться XML, для правильной работы с любым другим форматом вам придется разрабатывать и стандартизировать некоторый формат для ваших ссылок. Гиперссылки являются стандартными в XML, но не в JSON. Существуют стандарты стандартов для JSON, например HAL.
Наконец, REST не для всех, и доказательством тому является то, как большинство людей очень хорошо решают свои проблемы с API-интерфейсами HTTP, которые они ошибочно называют REST, и никогда не выходят за рамки этого. Иногда REST трудно делать, особенно в начале, но он платит со временем с более легкой эволюцией на стороне сервера и устойчивостью клиентов к изменениям. Если вам нужно что-то сделать быстро и легко, не беспокойтесь о том, чтобы получить право REST. Вероятно, это не то, что вы ищете. Если вам нужно что-то, что нужно будет оставаться в сети годами или даже десятилетиями, тогда REST для вас.
REST vs SOAP не правильный вопрос.
REST, в отличие от SOAP - это протокол не.
REST - это архитектурный стиль и дизайн сетевых архитектур на основе программного обеспечения.
REST понятия называются ресурсами. Представление ресурса должно быть неактивным. Он представлен через некоторый тип медиа. Некоторые примеры типов медиа включают XML, JSON и RDF. Ресурсы обрабатываются компонентами. Компоненты запрашивают и управляют ресурсами через стандартный унифицированный интерфейс. В случае HTTP этот интерфейс состоит из стандартных HTTP-операций, например. GET, PUT, POST, DELETE.
@Abdulaziz освещает тот факт, что REST и HTTP часто используются в тандеме. Это связано, прежде всего, с простотой HTTP и ее естественным отображением на принципы RESTful.
Коммуникация клиент-сервер
Архитектуры клиент-сервер имеют очень четкое разделение проблем. Все приложения, созданные в стиле RESTful, также должны быть клиент-сервером в принципе.
Stateless
Каждый запрос клиента на сервер требует, чтобы его состояние было полностью представлено. Сервер должен быть в состоянии полностью понять запрос клиента без использования какого-либо состояния сервера или состояния сеанса сервера. Из этого следует, что все состояние должно храниться на клиенте.
Cacheable
Кэшированные ограничения могут быть использованы, что позволяет указывать данные ответа как кэшируемые или не кэшируемые. Любые данные, помеченные как кэшируемые, могут быть повторно использованы в качестве ответа на один и тот же последующий запрос.
Равномерный интерфейс
Все компоненты должны взаимодействовать через единый унифицированный интерфейс. Поскольку взаимодействие всех компонентов происходит через этот интерфейс, взаимодействие с различными службами очень простое. Интерфейс тот же! Это также означает, что изменения в реализации могут быть сделаны изолированно. Такие изменения не повлияют на взаимодействие фундаментальных компонентов, поскольку равномерный интерфейс всегда остается неизменным. Один из недостатков заключается в том, что вы застряли в интерфейсе. Если оптимизация может быть предоставлена конкретной службе, изменив интерфейс, вам не повезло, поскольку REST запрещает это. Однако с яркой стороны REST оптимизирован для Интернета, поэтому невероятная популярность REST по HTTP!
Вышеупомянутые концепции представляют собой определяющие характеристики REST и различают архитектуру REST от других архитектур, таких как веб-службы. Полезно отметить, что служба REST является веб-службой, но веб-служба не обязательно является службой REST.
Смотрите этот блог post в Принципы дизайна REST для более подробной информации о REST и указанные выше пули.
EDIT: обновить контент на основе комментариев
SOAP (простой протокол доступа к объектам) и REST (передача состояния представления) прекрасны в своем роде. Поэтому я не сравниваю их. Вместо этого я пытаюсь изобразить картинку, когда я предпочел использовать REST и когда SOAP.
Что такое полезная нагрузка?
Когда данные отправляются через Интернет, каждая передаваемая единица включает в себя как информацию заголовка, так и фактические отправляемые данные. Заголовок идентифицирует источник и назначение пакета, в то время как фактические данные упоминаются как полезная нагрузка. В общем, полезная нагрузка - это данные, которые передаются от имени приложения, и данные, полученные системой назначения.
Теперь, например, мне нужно отправить телеграмму, и мы все знаем, что стоимость телеграммы будет зависеть от некоторых слов.
Так скажите мне среди упомянутых ниже двух этих сообщений, какое из них дешевле отправить?
<name>Arin</name>
или же
"name": "Arin"
Я знаю, что ваш ответ будет вторым, хотя оба, представляющие одно и то же сообщение, второе дешевле в отношении стоимости.
Поэтому я пытаюсь сказать, что отправка данных по сети в формате JSON дешевле, чем отправка данных в формате XML для полезной нагрузки.
Вот первое преимущество или преимущества REST перед SOAP. SOAP поддерживает только XML, но REST поддерживает другой формат, такой как текст, JSON, XML и т.д. И мы уже знаем, что если мы будем использовать Json, то определенно будем лучше в отношении полезной нагрузки.
Теперь SOAP поддерживает только XML, но также имеет свои преимущества.
В самом деле! Как?
SOAP опирается на XML тремя способами. Конверт - определяет, что находится в сообщении и как его обрабатывать.
Набор правил кодирования для типов данных и, наконец, компоновка вызовов процедур и собранных ответов.
Этот конверт отправляется через транспорт (HTTP/HTTPS), и выполняется RPC (удаленный вызов процедуры), а конверт возвращается с информацией в формате документа XML.
Важным моментом является то, что одним из преимуществ SOAP является использование "общего" транспорта, но REST использует HTTP/HTTPS. SOAP может использовать практически любой транспорт для отправки запроса, но REST не может. Таким образом, здесь мы получили преимущество использования SOAP.
Как я уже упоминал в предыдущем параграфе "REST использует HTTP/HTTPS", давайте углубимся в эти слова.
Когда мы говорим о REST через HTTP, все применяемые меры безопасности HTTP наследуются, и это известно как безопасность на транспортном уровне, и она защищает сообщения только тогда, когда она находится внутри сети, но как только вы доставили ее на другую сторону, вы не знаете, сколько этапы, которые он должен пройти, прежде чем достичь реальной точки, в которой будут обрабатываться данные. И, конечно, на всех этих этапах можно использовать что-то отличное от HTTP. Так что отдых не совсем безопасен, верно?
Но SOAP поддерживает SSL так же, как REST, кроме того, он также поддерживает WS-Security, который добавляет некоторые функции безопасности предприятия. WS-Security предлагает защиту от создания сообщения до его потребления. Таким образом, для безопасности на транспортном уровне, какую бы лазейку мы не обнаружили, это можно предотвратить с помощью WS-Security.
Кроме того, поскольку протокол REST ограничен протоколом HTTP, поэтому его поддержка транзакций не соответствует ни ACID, ни может обеспечить двухфазную фиксацию в распределенных транснациональных ресурсах.
Но SOAP имеет всестороннюю поддержку как управления транзакциями на основе ACID для краткосрочных транзакций, так и управления транзакциями на основе компенсации для длительных транзакций. Он также поддерживает двухфазную фиксацию через распределенные ресурсы.
Я не делаю никаких выводов, но я предпочту веб-сервис на основе SOAP, в то время как безопасность, транзакции и т.д. Являются главными проблемами.
Вот "Учебник по Java EE 6", в котором говорится, что дизайн RESTful может быть подходящим, когда выполняются следующие условия. Посмотри.
Надеюсь, вам понравилось читать мой ответ.
REST (RE презентационного S татэ T ransfer)
RE презентационного S Тейта объекта Т ransferred является REST т.е. мы не посылаем объект, мы отправляем состояние объекта. ОТДЫХ - это архитектурный стиль. Он не определяет так много стандартов, как SOAP. REST предназначен для демонстрации общедоступных API (например, API Facebook, API Карт Google) через Интернет для обработки операций CRUD с данными. REST ориентирован на доступ к именованным ресурсам через единый согласованный интерфейс.
SOAP (S реали O ▪ Таблица Д оступ Р rotocol)
SOAP предоставляет свой собственный протокол и фокусируется на представлении частей логики приложения (не данных) как сервисов. SOAP выставляет операции. SOAP ориентирован на доступ к именованным операциям, каждая операция реализует некоторую бизнес-логику. Хотя SOAP обычно называют веб-сервисами, это неправильно. SOAP имеет очень мало общего с Интернетом. REST предоставляет настоящие веб-сервисы на основе URI и HTTP.
Почему ОТДЫХ?
application/xml или application/json для POST и /user/1234.json или GET /user/1234.xml для GET.Почему мыло?
SOAP и веб-службы REST
Существует много различий между веб-службами SOAP и REST. Ниже приведены важные 10 различий между SOAP и REST:
Разница между отдыхом и мылом
SOAP
REST
Подробнее см. здесь
Решение между этими двумя будет вашим первым выбором при разработке веб-сервиса, поэтому важно понимать плюсы и минусы этих двух. Также важно, что в раздутых дискуссиях между двумя философиями можно отделить реальность от риторики.
Основы REST
Основы SOAP
SOAP vs REST?
Одним из основных преимуществ SOAP является то, что у вас есть описание службы WSDL. Вы можете в значительной степени обнаружить службу автоматически и создать полезный клиентский прокси из этого описания службы (сгенерировать вызовы служб, необходимые типы данных для методов и т.д.). Обратите внимание, что с версией 2.0 WSDL поддерживает все HTTP-глаголы и может использоваться для документирования служб RESTful, но для этой цели существует менее подробный вариант в WADL (Language Description Language).
С помощью служб RESTful безопасность сообщений обеспечивается транспортным протоколом (HTTPS) и только точка-точка. Он не имеет стандартной системы обмена сообщениями и ожидает, что клиенты будут реагировать на сбои в связи путем повторной попытки. SOAP имеет успешную/повторную логику и обеспечивает сквозную надежность даже через посредников SOAP.
Одним из основных преимуществ API RESTful является гибкость представления данных, например, вы можете сериализовать свои данные в формате XML или JSON. API RESTful более чисты или понятны, потому что они добавляют элемент использования стандартизованных URI и придают большое значение используемому глаголу HTTP (т.е. GET, POST, PUT и DELETE).
RESTful-сервисы также легки, то есть у них нет много дополнительной разметки xml. Чтобы вызывать RESTful API все, что вам нужно, это браузер или HTTP-стек, и почти все устройства или машины, подключенные к сети, имеют это.
Преимущества REST
Преимущества SOAP
Где использовать REST
области, в которых REST отлично работают, являются:
Где использовать SOAP
где SOAP работает как отличное решение:
Другие ответы дали обширные различия и подробно объяснили подробно. Поэтому я бы держался подальше от таких ответов и спрашивал вас, если вы все еще смущены, если это так, вам может понравиться взглянуть на эту простую аналогию.
ИМХО, вы не можете сравнивать SOAP и REST, где это две разные вещи.
SOAP - это протокол, а REST - архитектурный образец программного обеспечения. Существует много заблуждений в Интернете для SOAP vs REST.
SOAP определяет формат сообщений на основе XML, который использует приложения, поддерживающие веб-службы, для связи друг с другом через Интернет. Для этого приложения нуждаются в предварительном знании контракта с сообщением, типах данных и т.д.
REST представляет состояние (как ресурсы) сервера с URL-адреса. Он не имеет состояния и клиенты не должны иметь предварительные знания для взаимодействия с сервером, кроме понимания гипермедиа.
Прежде всего: официально, правильный вопрос будет
web services + WSDL + SOAPпротивREST.Потому что, хотя веб-служба используется в широком смысле, при использовании протокола HTTP для передачи данных вместо веб-страниц, официально, это очень специфическая форма этой идеи. Согласно определению, REST не является "веб-службой".
На практике, однако, все это игнорируют, так что пусть это тоже игнорируется
Уже есть технические ответы, поэтому я постараюсь дать некоторую интуицию.
Допустим, вы хотите вызвать функцию на удаленном компьютере, реализованную на каком-то другом языке программирования (это часто называют удаленным вызовом процедуры /RPC). Предположим, что функцию можно найти по определенному URL, предоставленному человеком, который ее написал. Вы должны (как-то) отправить ему сообщение и получить ответ. Итак, нужно рассмотреть два основных вопроса.
По первому вопросу официальное определение - WSDL. Это файл XML, который в подробном и строгом виде описывает, какие параметры, каковы их типы, имена, значения по умолчанию, имя вызываемой функции и т.д. Пример WSDL здесь показывает, что файл читается человеком (но не легко).
На второй вопрос есть разные ответы. Однако на практике используется только SOAP. Его основная идея: обернуть предыдущий XML (фактическое сообщение) в еще один XML (содержащий информацию о кодировке и другие полезные вещи) и отправить его по HTTP. Метод POST HTTP используется для отправки сообщения, так как всегда есть тело.
Основная идея всего этого подхода заключается в том, что вы сопоставляете URL-адрес с функцией, то есть с действием. Итак, если у вас есть список клиентов на каком-либо сервере, и вы хотите просмотреть/обновить/удалить его, у вас должно быть 3 URL:
myapp/read-customer и в теле сообщения передайте идентификатор клиента для чтения.myapp/update-customer и в теле, передайте идентификатор клиента, а также новые данныеmyapp/delete-customer и идентификатор в телеПодход REST видит вещи по-другому. URL-адрес должен представлять не действие, а вещь (называемую ресурсом в жаргоне REST). Поскольку протокол HTTP (который мы уже используем) поддерживает глаголы, используйте эти глаголы, чтобы указать, какие действия нужно выполнить с вещью.
Так, с подходом REST, клиент номер 12 будет найден в URL myapp/customers/12. Чтобы просмотреть данные клиента, вы нажимаете URL-адрес с помощью запроса GET. Чтобы удалить его, тот же URL, с глаголом DELETE. Чтобы обновить его, снова , тот же URL-адрес с глаголом POST и новое содержимое в теле запроса.
Подробнее о требованиях, которым должен соответствовать сервис, чтобы он считался действительно RESTful, см. в модели зрелости Ричардсона. В статье приводятся примеры и, что более важно, объясняется, почему (так называемая) служба SOAP является службой REST уровня 0 (хотя уровень 0 означает низкое соответствие этой модели, это не оскорбительно и все еще полезно во многих случаях).
Среди многих других, уже рассмотренных во многих ответах, я хотел бы отметить, что SOAP позволяет определять контракт, WSDL, который определяет поддерживаемые операции, сложные типы и т.д. SOAP ориентирован на операции, а REST ориентирован на ресурсы. Лично я бы выбрал SOAP для сложных интерфейсов между внутренними корпоративными приложениями и REST для общедоступных, простых интерфейсов без сохранения состояния с внешним миром.
Хорошо, я вижу, что в наши дни множество новых веб-сервисов реализованы с использованием архитектуры стиля REST, а не SOAP. Давайте отступим назад и объясним, что такое REST.
Что такое веб-служба REST
Аббревиатура REST означает передачу State State State Transfer, это означает, что каждый уникальный URL-адрес является представлением некоторого объекта. Вы можете получить содержимое этого объекта с помощью HTTP GET, чтобы удалить его, затем вы можете использовать POST, PUT или DELETE для изменения объекта (на практике большинство служб используют POST для этого).
Кто использует REST?
Все веб-службы Yahoo используют REST, в том числе API Flickr, del.icio.us, pubsub, bloglines, technorati, и eBay, и Amazon имеют веб-службы для REST и SOAP.
Кто использует SOAP?
Google швы должны быть последовательными в реализации своих веб-сервисов для использования SOAP, за исключением Blogger, который использует XML-RPC. Вы также найдете веб-службы SOAP в большом количестве корпоративного программного обеспечения.
REST vs SOAP
Как вы могли заметить, компании, о которых я упоминал, что используют REST api, не были очень долго, и их apis вышел в этом году в основном. Таким образом, REST - это, безусловно, модный способ создания веб-сервиса, если создание веб-сервисов может когда-либо быть модным (давайте рассмотрим его, мы используем мыло для мытья, а вы отдыхаете, когда устали).
Основные преимущества веб-служб REST:
SOAP также имеет некоторые преимущества:
Для использования веб-сервисов иногда бывает, что между ними это проще. Например, веб-сервис Google AdWords действительно сложно потреблять (в любом случае в CF), он использует заголовки SOAP и ряд других вещей, которые делают его довольно сложным. С другой стороны, веб-служба Amazon REST иногда может быть сложной для синтаксического анализа, поскольку она может быть сильно вложенной, а схема результата может варьироваться в зависимости от того, что вы ищете.
Какая бы архитектура ни выбрала, убедитесь, что разработчики легко ее получают и хорошо документированы.
Надеюсь, это поможет вам:)
Дополнение для:
++ Ошибка, возникающая при приближении к REST, заключается в том, чтобы думать о ней как о "веб-сервисах с URL-адресами" - думать о REST как о другом способе удаленного вызова процедур (RPC), например SOAP, но вызывается через простые URL-адреса HTTP и без SOAP больших пространств имен XML.
++ Напротив, REST имеет мало общего с RPC. В то время как RPC ориентирован на обслуживание и ориентирован на действия и глаголы, REST ориентирован на ресурсы, подчеркивая вещи и существительные, составляющие приложение.
Многие из этих ответов совершенно забыли упомянуть средства управления гипермедиа (HATEOAS), которые являются фундаментальными для REST. Несколько других коснулись этого, но не очень хорошо объяснили это.
Эта статья должна объяснить разницу между концепциями, не затрагивая некоторые особенности SOAP.
Мыло
• SOAP означает протокол простого доступа к объектам
• SOAP - это протокол связи приложений
• SOAP - это формат для отправки и получения сообщений
• SOAP не зависит от платформы
• SOAP основан на XML
• SOAP - рекомендация W3C
Почему SOAP?
• Для веб-приложений важно иметь возможность общаться через Интернет.
• Лучший способ общения между приложениями - HTTP, потому что HTTP поддерживается всеми браузерами и серверами Интернета. Для этого был создан SOAP.
• SOAP обеспечивает возможность взаимодействия между приложениями, работающими в разных операционных системах, с различными технологиями и языками программирования.
API REST
• Передача репрезентативного состояния. В нем описывается, как одна система может связывать состояние с другим. Одним из примеров может быть состояние продукта (его имя, описание и т.д.), Представленное как XML, JSON или обычный текст. Обобщенная идея состояния называется ресурсом.
SOAP Vs. REST
Веб-сервисы представляют собой набор независимых от платформы API-интерфейсов (функций), которые можно использовать с удаленного сервера через Интернет. По сути, в этом участвуют две стороны, одна из которых предоставляет набор открытых API, а другая, обычно известная как потребители веб-сервисов, является стороной, которая использует функциональные возможности и сервисы, предоставляемые стороной, предоставляющей веб-сервисы.
Подробнее здесь