МЫЛО против ОТДЫХА (различия)

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

1. REST более динамичен, нет необходимости создавать и обновлять UDDI (универсальное описание, обнаружение и интеграция).

2. REST не ограничивается только форматом XML. Веб-сервисы RESTful могут отправлять обычный текст / JSON / XML.

Но SOAP более стандартизирован (например, безопасность).

Итак, я прав в этих пунктах?

К сожалению, вокруг REST много дезинформации и заблуждений. Не только ваш вопрос, но и ответ @cmd , но и большинство вопросов и ответов по теме переполнения стека.

SOAP и REST нельзя сравнивать напрямую, поскольку первый - это протокол (или, по крайней мере, пытается это сделать), а второй - архитектурный стиль. Вероятно, это один из источников путаницы вокруг этого, поскольку люди склонны вызывать REST для любого HTTP API, который не является SOAP.

Немного подтолкнув и попробовав провести сравнение, основное различие между SOAP и REST заключается в степени связи между реализациями клиента и сервера. Клиент SOAP работает как пользовательское настольное приложение, тесно связанное с сервером. Между клиентом и сервером существует жесткий контракт, и ожидается, что все сломается, если какая-либо из сторон что-то изменит. Вам нужно постоянное обновление после любого изменения, но легче определить, соблюдается ли контракт.

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

Я думаю, что это ключевые моменты, чтобы понять, что такое REST и чем он отличается от SOAP:

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

• REST не является отображением CRUD для HTTP-методов. Прочитайте этот ответ для подробного объяснения этого.

• REST так же стандартизирован, как и используемые вами детали. Безопасность и аутентификация в HTTP стандартизированы, так что это то, что вы используете при выполнении REST через HTTP.

• ОТДЫХ - это НЕ ОТДЫХ без гипермедиа и HATEOAS . Это означает, что клиент знает только URI точки входа, а ресурсы должны возвращать ссылки, по которым должен следовать клиент. Те модные генераторы документации, которые предоставляют шаблоны URI для всего, что вы можете сделать в REST API, полностью упускают суть. Они не только документируют то, что должно следовать стандарту, но когда вы это делаете, вы связываете клиента с одним конкретным моментом в развитии API, и любые изменения в API должны документироваться и применяться, или это сломается.

• REST - это архитектурный стиль самой сети. Когда вы входите в Переполнение стека, вы знаете, что такое пользователь, вопрос и ответ, вы знаете типы мультимедиа, и веб-сайт предоставляет вам ссылки на них. REST API должен делать то же самое. Если бы мы создавали сеть так, как люди думают, что нужно сделать 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против SOAPэто не правильный вопрос , чтобы спросить.

REST, В отличие от SOAPэто не протокол.

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

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

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

Основные принципы ОТДЫХА

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

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

Stateless

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

Cacheable

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

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

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

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

См. Этот пост в блоге о принципах дизайна REST для получения более подробной информации о REST и вышеупомянутых пунктах.

РЕДАКТИРОВАТЬ: обновить контент на основе комментариев

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 Тейта объекта является T ransferred является REST , то есть мы не отправляем объект, мы отправляем состояние объекта. ОТДЫХ - это архитектурный стиль. Он не определяет так много стандартов, как SOAP. REST предназначен для демонстрации общедоступных API (например, API Facebook, API Карт Google) через Интернет для обработки операций CRUD с данными. REST ориентирован на доступ к именованным ресурсам через единый согласованный интерфейс.

SOAP ( S реали O ▪ Таблица ступа P rotocol) SOAP приносит свой собственный протокол и фокусируется на обнажая части логики приложения (не данные) в качестве услуг. SOAP выставляет операции. SOAP ориентирован на доступ к именованным операциям, каждая операция реализует некоторую бизнес-логику. Хотя SOAP обычно называют веб-сервисами, это неправильно. SOAP имеет очень мало общего с Интернетом. REST предоставляет настоящие веб-сервисы на основе URI и HTTP.

Почему ОТДЫХ?

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

Почему мыло?

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

источник1
источник2

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

МЫЛО

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

ОСТАТОК

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

Для более подробной информации, пожалуйста, смотрите здесь

ИМХО, вы не можете сравнить SOAP и REST, где это две разные вещи.

SOAP - это протокол, а REST - это программный паттерн архитектуры. Есть много заблуждений в Интернете о SOAP против 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, с глаголом УДАЛИТЬ. Чтобы обновить его, снова тот же URL с глаголом POST и новым содержимым в теле запроса.

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

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

Дополнение для:

++ Ошибка, которая часто допускается при обращении к REST, состоит в том, чтобы думать о ней как о «веб-сервисах с URL-адресами» - думать о REST как о другом механизме удаленного вызова процедур (RPC), таком как SOAP, но который вызывается через простые URL-адреса HTTP и без излишних SOAP-функций. Пространства имен XML.

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

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

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