WSDL против REST Плюсы и минусы
Связанные с:
При принятии решения о реализации веб-службы с использованием SOAP или REST (под RESTful я имею в виду HTTP/XML), что мне следует знать и о чем следует думать? Я предполагаю, что это не один размер подходит всем, так как мне выбрать, какой использовать.
13 ответов
Следующие ссылки предоставляют полезную информацию о 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) очень мало общего с фактическими значениями или ограничениями двух технологий. Вероятно, наиболее цитируемым про для REST является то, что он "легкий" или имеет тенденцию быть более "читаемым человеком". На одном уровне это, безусловно, верно, REST имеет более низкий барьер для входа - там меньше требуемой структуры, чем в SOAP (хотя я согласен с теми, кто сказал, что хороший инструмент - это в основном ответ здесь - слишком плохая большая часть инструментов SOAP довольно ужасно).
Однако, помимо этой первоначальной стоимости входа, я думаю, что впечатление от REST складывается из сочетания формы URL-адресов запроса и сложности данных, которыми обменивается большинство служб REST. REST имеет тенденцию поощрять более простые, более удобочитаемые URL-адреса запросов, и данные также становятся более удобочитаемыми. Однако в какой степени они присущи REST и в какой степени они просто случайны. Более простая структура URL является прямым результатом архитектуры - но она может быть одинаково хорошо применена к сервисам на основе SOAP. Более легко усваиваемые данные, скорее всего, будут результатом отсутствия какой-либо определенной структуры. Это означает, что вам лучше сохранять свои форматы данных простыми или вы будете заняты большой работой. Таким образом, здесь дополнительная структура SOAP, которая должна быть преимуществом, фактически обеспечивает небрежное проектирование, и этот неаккуратный дизайн затем используется как рывок против технологии.
Поэтому для использования в обмене структурированными данными между компьютерными системами я не уверен, что REST по своей природе лучше SOAP (или наоборот), они просто разные. Я думаю, что сравнение REST vs SOAP с динамической и статической типизацией является хорошим. Дианмические языки, как правило, сталкиваются с проблемами - это долгосрочное обслуживание и обслуживание системы (и в долгосрочной перспективе я не говорю год или два, я говорю 5 или 10). Будет интересно посмотреть, сталкивается ли REST с теми же проблемами со временем. Я склонен думать, что так и будет, если бы я строил распределенную систему обработки информации, я бы склонялся к SOAP в качестве механизма связи (также из-за многоуровневой передачи и прикладного протокола и гибкости, которую он обеспечивает, как было упомянуто выше).
В других местах, хотя REST кажется более подходящим. AJAX между клиентом и его сервером (независимо от полезной нагрузки) является одним из основных примеров. У меня нет особой заботы о долговечности этого типа соединения, а простота использования и гибкость как минимум. Точно так же, если мне нужен был быстрый доступ к какой-либо внешней службе, и я не думал, что буду заботиться о сохранности взаимодействия с течением времени (опять же, я предполагаю, что именно здесь REST обойдется мне дороже, в одну сторону или другой), тогда я мог бы выбрать REST только для того, чтобы я мог быстро входить и выходить.
В любом случае, они обе являются жизнеспособными технологиями, и в зависимости от того, какие компромиссы вы хотите сделать для данного приложения, они могут служить вам хорошо (или плохо).
REST не является протоколом; Это архитектурный стиль. Или парадигма, если хотите. Это означает, что SOAP определено гораздо слабее. Для базового CRUD вы можете опираться на стандартные протоколы, такие как Atompub, но для большинства сервисов у вас будет больше команд, чем просто.
Как потребитель, SOAP может быть благословением или проклятием, в зависимости от языковой поддержки. Поскольку SOAP в значительной степени моделируется в строго типизированной системе, он лучше всего работает со статически типизированными языками. Для динамического языка он может легко стать грубым и лишним. Кроме того, поддержка клиентских библиотек не так хороша за пределами мира Java и.NET
Мне следует быть осторожным, когда мы используем слово веб-сервис. Мы должны постоянно указывать, говорим ли мы о веб-службе 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.
Мы можем использовать, когда вы хотите сделать свой сервис максимально легким, например, звонить с мобильных устройств, таких как мобильный телефон, КПК и т. Д.
Для корпоративных систем, в которых ваша система ограничена внутри вашей корпорации, проще и правильнее использовать мыло, потому что вы почти контролируете клиентов. это проще, поскольку существует множество инструментов, которые создают классы (прокси) и выглядят так, как будто вы выполняете свой обычный ООП, который соответствует вашей среде Ja va или.net (в которой используется большинство корпораций).
Я бы использовал REST для интернет-приложений для отображения интерфейсов (таких как twitter api), так как клиенты могут использовать javascripts или html или другие, в которых типизация не является строгой. Отдых более либеральным имеет больше смысла.
Также для интернет-клиентов (всемирная паутина) легче анализировать json или xml, исходящие из интерфейса rest, а не чисто xml, исходящие из интерфейса soap. на ja vascript сложно использовать прокси, а ja vascript не поддерживает объекты. Если вы используете REST с ja vascript, вы обычно просто анализируете строку json, и все готово. Интерфейсы, обращенные к Интернету, обычно очень просты (поэтому в большинстве случаев это простой анализ) и обычно не требуют согласованности, поэтому REST достаточно адекватен.
Для корпоративных приложений я не думаю, что REST является адекватным, потому что транзакции, безопасность, строгая типизация, схемы играют очень важную роль в разработке корпоративных приложений, поэтому SOAP больше подходит для них.
Мой вывод заключается в том, что SOAP для корпоративных систем, REST для Интернета или WWW. Вы можете использовать его взаимозаменяемо, но вы можете столкнуться с трудностями, когда в конечном итоге не будете использовать подходящий инструмент для работы.
Извините за мой плохой английский.
В защиту REST он тесно следует принципам HTTP и адресуемости, например, операции чтения используют GET, операции обновления используют POST и т. Д. Я считаю, что это гораздо более чистый подход. Книга Oreilly RESTful Web Services объясняет это гораздо лучше, чем я, если вы прочитаете это, я думаю, вы бы предпочли подход REST
Предыдущие ответы содержат много информации, но я думаю, что есть философское различие, которое не было указано. SOAP был ответом на вопрос "как создать современного, объектно-ориентированного, независимого от платформы и протокола преемника RPC?". REST возник из вопроса: "Как нам понять, почему HTTP стал настолько успешным для сети, и использовать их для распределенных вычислений?"
SOAP - это инструмент, позволяющий сделать распределенное программирование похожим на... программирование. REST пытается навязать стиль для упрощения распределенных интерфейсов, чтобы распределенные ресурсы могли ссылаться друг на друга, как распределенные HTML-страницы могут ссылаться друг на друга. Один из способов сделать это - попытка (в основном) ограничить операции "CRUD" на ресурсах (создание, чтение, обновление, удаление).
REST еще молод - хотя он ориентирован на "удобочитаемые" службы, он не исключает служб самоанализа и т. Д. Или автоматического создания прокси. Однако они не были стандартизированы (как я пишу). SOAP дает вам эти вещи, но (IMHO) дает вам "только" эти вещи, в то время как стиль, наложенный REST, уже стимулирует распространение веб-сервисов из-за его простоты. Я бы сам посоветовал начинающим поставщикам услуг выбирать REST, если только им не нужно использовать определенные функции, предоставляемые SOAP.
По моему мнению, тогда, если вы внедряете API "с нуля" и не знаете так много о возможных клиентах, я бы выбрал REST, поскольку поощряемый им стиль помогает сделать интерфейсы понятными и легкими для разработки. Если вы много знаете о клиенте и сервере, и есть специальные инструменты SOAP, которые облегчат жизнь обоим, тогда я не буду религиозен в отношении REST.
Набор инструментов на стороне клиента будет один. А знакомство с SOAP-сервисами другое. В наши дни все больше и больше сервисов отправляются по маршруту RESTful, и тестирование таких сервисов может быть выполнено на простых примерах cURL. Хотя не так сложно реализовать оба метода и обеспечить максимально широкое использование клиентами.
Если вам нужно выбрать один, я бы предложил REST, это проще.
Вы можете легко перенести веб-компоненты WCF, изобилующие WSDL, в другое использование, просто изменив настройки конфигурации. Вы можете переходить по HTTP, а затем именовать каналы, tcp, настраиваемые протоколы и т. Д. Без необходимости изменения кода. Я полагаю, что компоненты WCF также проще настроить для таких вещей, как безопасность, двусторонняя связь, транзакции, параллелизм и т. Д.
REST в значительной степени ограничивает вас HTTP (что хорошо во многих случаях).
Я знаю, что это обсуждение является старым, но после прочтения всех ответов и комментариев, я считаю, что все упустили самый важный момент о разнице между двумя системами: SOAP использует сложные типы, чтобы не только предоставлять вам данные, но и проверять это и держите это в строгом обозначении типа, для которого это было определено. WSDL сообщает вам, что такое формат данных, каков тип данных, позволяет вам добавлять правила шаблонного стиля reg-ex и определяет, сколько раз часть данных должна быть и может быть разрешена в запросе / ответе., Отдых с другой стороны не имеет ни одного из этих механизмов.
SOAP сложен и тяжел, потому что позволяет отправлять сложные тяжелые иерархические данные. REST - это простой текст с исходной и конечной точками, сортирующими правила.
SOAP не зависит от бизнеса, поскольку в него включены все правила данных, встроенные в документ.
Разница между SOAP и REST заключается в том, что SOAP представляет собой автономную бизнес-ориентированную схему. REST - это текстовый документ.