Связанный:
При принятии решения о том, следует ли внедрять веб-службу с использованием SOAP или REST (под которым я подразумеваю HTTP/XML с помощью RESTful), что я должен знать и о чем я должен думать? Я предполагаю, что это не один размер подходит всем, так как я могу выбрать, что использовать.
Следующие ссылки содержат полезную информацию о WSDL и REST, включая "Плюсы и минусы".
Пара ключевых моментов состоит в том, что
1) SOAP был разработан для распределенной вычислительной среды, где REST был разработан для среды с точки зрения точки.
2) WADL может использоваться для определения интерфейса для служб REST.
http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and-wadl
Два протокола имеют очень разные применения в реальном мире.
SOAP (используя WSDL) - это тяжелый XML-стандарт, который сосредоточен вокруг прохождения документа. Преимущество заключается в том, что ваши запросы и ответы могут быть очень хорошо структурированы и даже могут использовать DTD. Недостатком является XML и очень многословный. Однако это хорошо, если у двух сторон должен быть строгий контракт (например, для межбанковского общения). SOAP также позволяет вам накладывать на ваши документы такие вещи, как WS-Security. SOAP обычно является транспортно-агностическим, то есть вам необязательно использовать HTTP.
REST очень легкий и полагается на стандарт HTTP, чтобы он работал. Очень полезно быстро и быстро запустить полезный веб-сервис. Если вам не нужен строгий API, это путь. Большинство веб-сервисов относятся к этой категории. Вы можете обновить API, чтобы обновления API не прерывали его для людей, использующих старые версии (при условии, что они указывают версию). REST по существу требует HTTP и является агматическим форматом (это означает, что вы можете использовать XML, JSON, HTML и т.д.).
Обычно я использую REST, потому что мне не нужны фантастические WS- * функции. SOAP хорош, хотя если вы хотите, чтобы компьютеры понимали ваш веб-сервис с помощью WSDL. Спецификации REST обычно доступны только для людей.
Что касается WSDL (что означает "SOAP" ) как "тяжелый". Насколько тяжело? Если набор инструментов выполняет весь "тяжелый подъем" для вас, то почему это имеет значение?
Мне еще не нужно было использовать сложный REST API. Когда я это сделаю, я ожидаю, что захочу для WSDL, который мои инструменты с радостью преобразуют в набор прокси-классов, поэтому я могу просто назвать то, что представляется методом. Вместо этого я подозреваю, что для того, чтобы потреблять нетривиальный API на основе REST, необходимо будет вручную написать значительное количество "легкого" кода.
Даже когда все это будет сделано, вы по-прежнему будете переводить удобочитаемую документацию в код, со всем сопутствующим риском, чтобы люди не ошибались. Поскольку WSDL является машиносчитываемым описанием службы, гораздо труднее "прочитать это неправильно".
Просто примечание: с этого поста у меня была возможность работать с умеренно сложным сервисом REST. Я действительно хотел получить WSDL или эквивалент, и мне действительно нужно было написать много кода вручную. Фактически, значительная часть времени разработки была потрачена на удаление дублирования кода всего кода, который назывался различными операциями обслуживания "вручную".
Это, вероятно, действительно относится к комментариям в некоторых из вышеперечисленных сообщений, но у меня пока нет ответа на это, так что здесь идет.
Я думаю, что интересно, что многие плюсы и минусы, часто цитируемые для SOAP и REST, имеют (IMO) очень мало общего с фактическими значениями или ограничениями двух технологий. Вероятно, наиболее цитируемый pro для REST - это то, что он "легкий" или имеет тенденцию быть более "читаемым человеком". На одном уровне это, безусловно, верно, у REST есть более низкий барьер для входа - структура менее требуема, чем SOAP (хотя я согласен с теми, кто сказал, что хороший инструмент в основном является ответом здесь - слишком большая часть инструмента SOAP довольно ужасно).
Помимо этой начальной стоимости входа, я думаю, что впечатление REST происходит от комбинации формы URL-адресов запросов и сложности данных, которыми обмениваются большинство служб REST. REST имеет тенденцию поощрять более простые, более понятные для пользователя URL-адреса запросов, и данные также более усваиваются. В какой степени они присущи REST и в какой степени они просто случайны. Более простая структура URL-адресов является прямым результатом архитектуры, но она может быть одинаково хорошо применима к службам на основе SOAP. Более усвояемые данные, скорее всего, будут связаны с отсутствием какой-либо определенной структуры. Это означает, что вам лучше хранить ваши форматы данных просто, или вы собираетесь работать очень много. Таким образом, здесь дополнительная структура SOAP, которая должна быть полезной, на самом деле обеспечивает неаккуратный дизайн, и эта неаккуратная конструкция затем используется в качестве копания против технологии.
Итак, для использования в обмене структурированными данными между компьютерными системами я не уверен, что REST по своей сути лучше, чем SOAP (или наоборот), они просто разные. Я думаю, что сравнение выше REST и SOAP с динамическим и статическим типированием является хорошим. Там, где диамантические языки, как правило, сталкиваются с проблемами, - это долгосрочное обслуживание и поддержание системы (и в долгосрочной перспективе я не говорю год или два, я говорю 5 или 10). Будет интересно узнать, работает ли REST с теми же проблемами с течением времени. Я склонен думать, что так будет, если бы я строил распределенную систему обработки информации, я бы стал тяготеть к SOAP в качестве механизма связи (также из-за иерархии протоколов и протоколов приложений и гибкости, которые она дает, как было упомянуто выше).
В других местах, хотя REST кажется более подходящим. AJAX между клиентом и его сервером (независимо от полезной нагрузки) является одним из основных примеров. Я не очень забочусь о долговечности такого типа связи, а простота в использовании и гибкость в премульте. Точно так же, если мне нужен быстрый доступ к некоторым внешним сервисам, и я не думал, что буду заботиться о поддерживаемости взаимодействия с течением времени (опять же я предполагаю, что здесь REST будет стоить мне больше, в одном направлении или другой), тогда я мог бы выбрать REST, чтобы я мог быстро и быстро войти.
В любом случае, они являются жизнеспособными технологиями и в зависимости от того, какие компромиссы вы хотите сделать для данного приложения, они могут служить вам хорошо (или плохо).
REST не является протоколом; Это архитектурный стиль. Или парадигма, если хотите. Это означает, что он намного слабее определил, что SOAP. Для базового CRUD вы можете опираться на стандартные протоколы, такие как Atompub, но для большинства служб у вас будет больше команд, чем только это.
Как потребитель, SOAP может быть благословением или бичем, в зависимости от поддержки языка. Поскольку SOAP очень сильно моделируется на строго типизированной системе, он лучше всего работает со статически типизированными языками. Для динамического языка он может легко стать жестоким и излишним. Кроме того, поддержка клиентской библиотеки не так хороша вне мира Java и .NET.
Для меня нужно быть осторожным, когда мы используем слово web-сервис. Мы должны все время указывать, говорим ли мы о веб-сервисе SOAP, веб-службе REST или других веб-службах, потому что мы говорим о разных вещах здесь, и люди больше не понимают, если мы назвали все их веб-сервисы.
В основном веб-службы SOAP очень хорошо работают в течение многих лет, и они следуют строгой спецификации, описывающей, как общаться с ними на основе спецификации SOAP. Теперь веб-службы REST немного новее и в основном выглядят проще, потому что они не используют какой-либо протокол связи. В основном то, что вы отправляете и получаете, когда используете веб-службу REST, является простым XML. Людям нравится, потому что они могут анализировать xml так, как они хотят, не имея дело с более сложным протоколом связи, таким как SOAP.
Для меня службы REST похожи, если вы создадите сервлет вместо веб-службы SOAP. Сервлет получает данные и возвращает данные. Формат данных основан на xml. Мы также можем предположить, что хотим использовать что-то еще, кроме xml, если хотим. Например, теги могут использоваться вместо xml, и это не будет REST, а что-то еще (может быть даже легче по весу, потому что xml не является естественным). Мы бы назвали это еще веб-службой? Да, мы могли бы, но это не будет соответствовать текущему стандарту, и это главная проблема здесь, если мы начнем звонить все веб-сервисы, но мы можем сделать это так, как мы хотим, тогда мы теряем на стороне взаимодействия вещи. Это означает, что формат данных, которые обмениваются с веб-службой, уже не стандартизирован. Для этого требуется, чтобы сервер и клиент согласовали формат данных, тогда как с SOAP это все предопределено уже, и сервер и клиент могут взаимодействовать друг с другом, не знакомы друг с другом, потому что они следуют одному и тому же стандарту.
То, что людям не нравится с SOAP, заключается в том, что им трудно понять это, и они не могут генерировать запросы вручную. Компьютеры могут делать это очень хорошо, так что это то, где нам нужно быть ясным: запросы веб-сервисов и ответ, которые предполагается использовать непосредственно конечным пользователям, или мы согласны с тем, что веб-службы находятся под API, называемые компьютерными системами на основе некоторых нормализованных стандарты?
SOAP. Он также может быть передан с помощью SMTP. Это означает, что мы можем вызывать службу, используя простой текстовый формат электронной почты.
Ему нужна дополнительная фреймворк/движок, который должен быть в машине пользователя веб-сервиса для преобразования SOAP-сообщения в соответствующую структуру объектов на разных языках.
REST: теперь WSDL2.0 поддерживает описание веб-службы REST также
Мы можем использовать, когда вы хотите сделать свой сервис легким, например, вызов с мобильных устройств, таких как сотовый телефон, КПК и т.д.
для корпоративных систем, в которых ваша система ограничена внутри ваших корпораций, ее проще и правильнее использовать мыло, потому что вы почти контролируете клиентов. это проще, поскольку существует множество инструментов, которые создают классы (прокси) и выглядят так, как будто вы делаете свой обычный OOP, который соответствует вашей среде java или .net(в которой используются большинство корпораций).
Я бы использовал REST для приложений, ориентированных на Интернет, для демонстрации интерфейсов (например, twitter api), поскольку клиенты могут использовать javascripts или html или другие, в которых типизация не является строгой. REST, являющийся более либеральным, имеет больше смысла.
Кроме того, для клиентов, ориентированных на Интернет (всемирная паутина), его легче разбирать json или xml, выходящие из интерфейса отдыха, а не просто xml, исходящие из интерфейса мыла. сложно использовать прокси-серверы на javascript, и javascript, естественно, не поддерживает объекты. Если вы используете REST с javascript, вы просто просто разбираете строку json, и вы уходите. интерфейсы, ориентированные на Интернет, обычно очень просты (поэтому в большинстве случаев его простой синтаксический анализ) и обычно не требуют согласованности, поэтому REST достаточно адекватен.
Для корпоративных приложений я не считаю REST адекватным, потому что транзакции, безопасность, строгая типизация, схемы играют очень важную роль в разработке корпоративных приложений, поэтому SOAP больше подходит для них.
Я пришел к выводу, что SOAP предназначен для корпоративных систем, REST - для Интернета или WWW. Вы можете использовать его взаимозаменяемо, но вы можете столкнуться с трудным временем, в конечном итоге не используя правильный инструмент для работы.
Извините за мой плохой английский.
В защиту REST он строго следует принципам HTTP и адресности, например. операции чтения используют GET, операции обновления используют POST и т.д. Я считаю, что это намного более чистый подход. Книга Oreilly RESTful Web Services объясняет это намного лучше, чем я могу, если вы ее прочтете, я думаю, что вы предпочтете подход REST
Набор инструментов на стороне клиента будет одним. И знакомство с SOAP-сервисами - другое. Все больше и больше услуг идут по маршруту RESTful в эти дни, и тестирование таких сервисов может быть выполнено с помощью простых примеров cURL. Хотя, это не все, что трудно реализовать оба метода и позволяют наиболее широкое использование клиентов.
Если вам нужно выбрать один, я предлагаю REST, это проще.
Предыдущие ответы содержат много информации, но я думаю, что есть философская разница, о которой не было сказано. SOAP был ответом на вопрос "как создать современный, объектно-ориентированный, платформенный и независимый от протокола преемник RPC?". REST, исходя из вопроса, "как нам понять, что делает HTTP настолько успешным для Интернета, и использовать их для распределенных вычислений?"
SOAP - это предоставление вам инструментов для того, чтобы распределенное программирование выглядело как... программирование. REST пытается навязать стиль для упрощения распределенных интерфейсов, так что распределенные ресурсы могут ссылаться друг на друга, так как распределенные html-страницы могут ссылаться друг на друга. Один из способов сделать это - попытка (в основном) ограничить операции "CRUD" на ресурсах (создавать, читать, обновлять, удалять).
REST еще молод - хотя он ориентирован на "читаемые человеком" услуги, он не исключает возможности интроспекции и т.д. или автоматического создания прокси. Однако они не были стандартизированы (как я пишу). SOAP дает вам эти вещи, но (IMHO) дает вам "только" эти вещи, тогда как стиль, наложенный REST, уже поощряет распространение веб-сервисов из-за его простоты. Я бы сам рекомендовал новичкам-провайдерам выбирать REST, если нет конкретных функций, поддерживаемых SOAP, которые им нужно использовать.
На мой взгляд, если вы внедряете API-интерфейс "greenfield" и не знаете, что о возможных клиентах, я бы выбрал REST, поскольку стиль, который он поощряет, имеет тенденцию помогать сделать интерфейсы понятными и легко развиваться к. Если вы много знаете о клиенте и сервере, и есть определенные инструменты SOAP, которые облегчат жизнь для обоих, тогда я бы не был религиозным в REST.
Вы можете легко перевести свои WSDL-spewing веб-компоненты WCF в другие приложения, просто изменив параметры конфигурации. Вы можете переходить через HTTP, а затем также именованные каналы, tcp, пользовательские протоколы и т.д., Не меняя свой код. Я считаю, что компоненты WCF также могут быть проще настроить для таких вещей, как безопасность, двухсторонний вызов, транзакции, concurrency и т.д.
REST довольно сильно ограничивает вас HTTP (во многих случаях это нормально).
Я знаю, что это обсуждение является старым, но, прочитав все ответы и прокомментировав, я считаю, что каждый пропустил самый важный момент в разнице между двумя системами: SOAP использует сложные типы, чтобы не только дать вам данные, но подтвердите его и сохраните в строгом типе, для которого он был определен. WSDL сообщает вам, что такое формат данных, каков тип данных, позволяет добавлять правила стиля шаблона reg-ex и определяет, сколько раз часть данных должна быть и может быть разрешена в запросе/ответе, В остальном с другой стороны нет ни одного из этих механизмов.
SOAP сложна и тяжела, поскольку позволяет отправлять сложные тяжелые иерархические данные. REST - это обычный текст, где исходный и конечный точки сортируют правила.
SOAP не зависит от бизнеса, поскольку он содержит все правила данных, встроенные в документ.
Разница между SOAP и REST заключается в том, что SOAP является самодостаточной бизнес-ориентированной схемой. REST - текстовый документ.