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

Question

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

1. REST более динамичен, нет необходимости создавать и обновлять UDDI.

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

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

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

Answer 1

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

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

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

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

Я думаю, что это ключевые моменты, чтобы понять, что такое 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 stackru.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 для вас.

Answer 2

REST против 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-сервисом.

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

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

Answer 3

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 может быть подходящим при соблюдении следующих условий. Посмотри.

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

Answer 4

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

SOAP (реализует протокол доступа)
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 для одного и того же ресурса в зависимости от параметра заголовка запроса "Принять", как application/xml или же application/json для POST и /user/1234.json или ПОЛУЧИТЬ /user/1234.xml для получения.
• Службы REST предназначены для вызова клиентским приложением, а не конечным пользователем напрямую.
• ST в REST происходит от S Tate Transfer. Вы передаете состояние вместо того, чтобы сервер сохранял его, это делает службы REST масштабируемыми.

Почему мыло?

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

source1
source2

Answer 5

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

Answer 6

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

МЫЛО

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.

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

Answer 7

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

REST основы

• Все в REST рассматривается как ресурс.
• Каждый ресурс идентифицируется URI.
• Использует единые интерфейсы. Ресурсы обрабатываются с использованием операций POST, GET, PUT, DELETE, которые аналогичны операциям создания, чтения, обновления и удаления (CRUD).
• Быть без гражданства. Каждый запрос является независимым запросом. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса.
• Связь осуществляется через представительства. Например, XML, JSON RESTful веб-сервисы. Веб-сервисы RESTful основаны на методах HTTP и концепции REST. Веб-сервис RESTful обычно определяет базовый URI для сервисов; поддерживаемые MIME-типы (XML, текст, JSON, пользовательские, ...) и набор операций (POST, GET, PUT, DELETE), которые поддерживаются.

Основы SOAP

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

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

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

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

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

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

Преимущества ОТДЫХА

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

Преимущества SOAP

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

Где использовать ОТДЫХ

области, в которых хорошо работает REST:

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

Где использовать SOAP

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

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

Answer 8

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

SOAP - это протокол, а REST - это программный паттерн архитектуры. В Интернете много заблуждений относительно SOAP и REST.

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

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

Answer 9

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

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

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

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

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

Таким образом, при подходе SOAP (опять-таки, неправильный термин), если у вас есть список клиентов, и вы хотите просмотреть / обновить / удалить его, у вас будет 3 URL:

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

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

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

Answer 10

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

Answer 11

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

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

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

Answer 12

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

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

Answer 13

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

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

Answer 14

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

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

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

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

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

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

Что такое SOAP API? SOAP - это стандартная система протоколов связи, которая позволяет процессам, использующим различные операционные системы, такие как Linux и Windows, обмениваться данными через HTTP и его XML. API на основе SOAP предназначены для создания, восстановления, обновления и удаления таких записей, как учетные записи, пароли, потенциальные клиенты и пользовательские объекты.

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

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

• REST API вообще не имеет официального стандарта, потому что это архитектурный стиль. SOAP API, с другой стороны, имеет официальный стандарт, потому что это протокол.
  • API REST использует несколько стандартов, таких как HTTP, JSON, URL и XML, а API-интерфейсы SOAP в значительной степени основаны на HTTP и XML.
  • Поскольку REST API развертывает несколько стандартов, он требует меньше ресурсов и пропускной способности по сравнению с SOAP, который использует XML для создания полезной нагрузки и приводит к файлу большого размера.
  • Способы, которыми оба API раскрывают бизнес-логику, также различны. REST API использует преимущества экспозиции URL, такие как @path("/WeatherService"), в то время как SOAP API использует интерфейсы сервисов, такие как @WebService.
  • SOAP API определяет слишком много стандартов, и его разработчик реализует вещи только стандартным способом. В случае неправильного общения со службой, результатом будет ошибка. REST API, с другой стороны, не делает акцента на слишком многих стандартах и ​​в итоге приводит к повреждению API.
  • REST API использует язык описания веб-приложений, а SOAP API использует язык описания веб-сервисов для описания функций, предлагаемых веб-сервисами.
  • API-интерфейсы REST более удобны в JavaScript и также могут быть легко реализованы. API-интерфейсы SOAP также удобны при использовании JavaScript, но не поддерживают большую реализацию.

---

Answer 15

ОТДЫХА API

RESTful API — самый известный тип API. REST означает передачу представительного состояния.

REST API — это API, которые следуют стандартизированным принципам, свойствам и ограничениям.

Вы можете получить доступ к ресурсам в REST API, используя HTTP-команды.

REST API работают в простой системе запросов/ответов. Вы можете отправить запрос, используя эти методы HTTP:

• ПОЛУЧИТЬ
• ПОЧТА
• ПОМЕЩАТЬ
• ПЛАСТЫРЬ
• УДАЛИТЬ
• СЛЕД
• ОПЦИИ
• СОЕДИНЯТЬ
• ГЛАВА

Вот наиболее распространенные глаголы HTTP

• ПОЛУЧИТЬ (прочитать существующие данные)
• POST (создать новый ответ или данные)
• ПАТЧ (обновить данные)
• УДАЛИТЬ (удалить данные)

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

Конечная точка (или маршрут) — это URL-адрес, который вы запрашиваете. Путь определяет ресурс, который вы запрашиваете.

Когда вы отправляете запрос на конечную точку, она отвечает соответствующими данными, обычно в формате JSON, XML, обычного текста, изображений, HTML и т. д.

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

Фактический RESTful API следует следующим пяти ограничениям:

1. Архитектура клиент-сервер
   . Клиент запрашивает данные с сервера без сторонней интерпретации.

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

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

4. Многоуровневость
   Различные уровни архитектуры API должны работать вместе, создавая масштабируемую систему, которую легко обновлять или настраивать.

5. Унифицированный интерфейс
   Общение между клиентом и сервером должно осуществляться на стандартизированном языке, который не зависит от них обоих. Это улучшает масштабируемость и гибкость.

API REST хорошо подходят для проектов, которые необходимо

• Гибкий
• Масштабируемость
• Быстро

SOAP-API

SOAP — это необходимый протокол, который помог широко использовать API.

SOAP — это аббревиатура от Simple Object Access Protocol.

SOAP — это стандартизированный протокол, использующий XML для отправки запросов и получения ответов.

Несмотря на то, что SOAP основан на XML, протокол SOAP по-прежнему широко используется.

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

Первоначально SOAP был разработан для Microsoft в 1998 году, чтобы предоставить стандартный механизм интеграции служб в Интернете независимо от операционной системы, объектной модели или языка программирования.

«S» в слове SOAP означает «простой», и на то есть веская причина — SOAP можно использовать с меньшей сложностью, поскольку он требует меньше кода на уровне приложения для транзакций, безопасности и других функций.

SOAP имеет три основные характеристики:

1. Расширяемость SOAP API
   SOAP позволяет использовать расширения, которые вводят более надежные функции, такие как безопасность Windows Server, адресация и другие.

2. Нейтральность SOAP API
   SOAP может работать с широким спектром протоколов, таких как UDP, JMS, SMTP, TCP и HTTP.

3. Независимость от SOAP
   API Ответы SOAP API полностью основаны на XML. Поэтому API-интерфейсы SOAP не зависят от платформы и языка.

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

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

• SOAP более безопасен, чем REST, поскольку использует WS-Security для передачи вместе с Secure Socket Layer.

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

Answer 16

Архитектуры веб-сервисов — это платформы для создания и интеграции программных систем, которые могут обмениваться данными через Интернет. Вот некоторые из наиболее часто используемых архитектур веб-сервисов.

SOAP (простой протокол доступа к объектам)

SOAP — это протокол обмена сообщениями на основе XML, используемый для обмена структурированными данными между веб-службами. Он определяет стандартизированный набор правил и протоколов для формата сообщений запроса и ответа, а также операций, которые могут выполняться в веб-сервисе.

Преимущества:

• Поддерживает различные транспортные протоколы (такие как HTTP, SMTP, TCP и другие).

• Обеспечивает надежный обмен сообщениями и функции безопасности.

• Может использоваться с любым языком программирования

Недостатки:

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

Примеры:

• Финансовые системы, которым требуется безопасный и надежный обмен сообщениями для транзакций.
• Системы здравоохранения, требующие строгого соблюдения нормативных стандартов

REST (Передача представительского состояния)

REST — это архитектурный стиль, использующий HTTP (протокол передачи гипертекста) для обмена данными между клиентами и серверами. Веб-службы RESTful используют стандартные методы HTTP (такие как GET, POST, PUT и DELETE) для выполнения операций над ресурсами (например, объектами данных), идентифицируемыми URL-адресами (унифицированными локаторами ресурсов).

Преимущества:

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

Недостатки:

• Ограниченная поддержка управления транзакциями и безопасности.
• Может быть сложно разработать правильный API для сложных систем.
• Нет стандартного формата сообщений.

Примеры:

• Платформы социальных сетей, которым требуется быстрый и эффективный доступ к данным для больших баз пользователей.
• Мобильные приложения, требующие низкой задержки и высокой производительности

RPC (удаленный вызов процедур)

RPC — это протокол, используемый для связи между приложениями, работающими в разных системах. Он позволяет клиенту вызывать процедуру (или метод) на удаленном сервере, как если бы это был вызов локального метода.

Преимущества:

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

Недостатки:

• Ограниченная поддержка распределенных транзакций и безопасности
• Может быть сложно масштабировать и управлять большими системами.
• Может потребоваться более сложная обработка ошибок

Примеры:

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

ГрафQL

GraphQL — это язык запросов и среда выполнения для API, которая позволяет клиентам точно указывать, какие данные им нужны, и получать обратно только эти данные. Он обеспечивает гибкий и эффективный способ получения данных с сервера, сокращая объем данных, передаваемых по сети.

Преимущества:

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

Недостатки:

• Может быть сложно разрабатывать и оптимизировать запросы для сложных систем. Ограниченная поддержка кэширования и безопасности.
• Могут потребоваться дополнительные усилия по разработке по сравнению с традиционными REST API.

Примеры:

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

Вебсокет

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

Преимущества:

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

Недостатки:

• Требуется поддержка двунаправленной связи на клиенте и сервере. Ограниченная поддержка маршрутизации и безопасности.
• Может быть сложнее реализовать по сравнению с традиционными REST API.

Примеры:

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

Answer 17

Что такое REST

REST означает передачу репрезентативного состояния, на самом деле это архитектурный стиль для создания веб-API, который рассматривает все (данные или функциональность) как обращение. Он ожидает; предоставление ресурсов через URI и ответ в нескольких форматах, а также репрезентативная передача состояния ресурсов без сохранения состояния. Здесь я говорю о двух вещах:

1. Способ без сохранения состояния: предоставляется по HTTP.
2. Репрезентативный перенос состояния: например, если мы добавляем сотрудника. . в нашу систему он находится в состоянии POST HTTP, после этого он будет в состоянии GET HTTP, PUT и DELETE аналогичным образом.

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

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

HATEOAS, сокращение от Hypermedia As The Engine Of Application State, является ограничением архитектуры приложения REST, которое отличает его от большинства других архитектур сетевых приложений. Принцип заключается в том, что клиент взаимодействует с сетевым приложением полностью через гипермедиа, динамически предоставляемую серверами приложений. Клиенту REST не требуются предварительные знания о том, как взаимодействовать с каким-либо конкретным приложением или сервером, помимо общего понимания гипермедиа. Напротив, в некоторых сервис-ориентированных архитектурах (SOA) клиенты и серверы взаимодействуют через фиксированный интерфейс, совместно используемый посредством документации или языка описания интерфейса (IDL).

Ссылка 1 Ссылка 2

Answer 18

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

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

Объектно-ориентированные архитектуры произошли от многоуровневых архитектур и следуют гораздо более свободной модели. Здесь каждый компонент представляет собой объект (часто называемый распределенным объектом). Объекты взаимодействуют друг с другом, используя механизм, аналогичный удаленным вызовам процедур - когда клиент привязывается к распределенному объекту, он загружает реализацию интерфейса объектов в свое адресное пространство. Заглушка RPC может маршалировать запрос и получать ответ. Точно так же интерфейс объектов на сервере представляет собой заглушку в стиле RPC. Поток данных в этих объектно-ориентированных системах не является однонаправленным, он больше похож на граф объектов ...

Интерфейс распределенного объекта скрывает его реализацию. Как и в случае многоуровневых компонентов, если интерфейс четко определен, внутренняя реализация может быть изменена - даже полностью заменена. Объектно-ориентированные архитектуры обеспечивают основу для инкапсуляции сервисов. Сервис может быть предоставлен автономным объектом, хотя внутри он может использовать другие сервисы. Постепенно объектно-ориентированные архитектуры превратились в сервис-ориентированные архитектуры (SOA). 


В SOA распределенное приложение состоит из сервисов. Эти услуги могут предоставляться в административных доменах - они могут быть доступны через Интернет (т. Е. Услуга хранения, предлагаемая поставщиком облачных услуг).

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


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

Архитектуры, основанные на ресурсах, представляли собой другой подход к решению проблем интеграции SOA. Идея состоит в том, чтобы рассматривать распределенную систему как гигантский набор ресурсов, которые индивидуально управляются компонентами. Это привело к разработке архитектур RESTful. Одна вещь, которая характеризует службы RESTful, - это выполнение без сохранения состояния. Это отличается от SOA, где сервер поддерживает состояние.

Итак ... как интерфейсы для конкретных служб, предоставляемые архитектурами, ориентированными на службы (включая те, которые используют SOAP), сравниваются с архитектурами RESTful?



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

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

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

Answer 19

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