МЫЛО - Какой смысл?

Question

Я имею в виду, действительно, какой смысл SOAP?

Веб-сервисы существовали некоторое время, и какое-то время казалось, что термины «SOAP» и «Веб-сервис» в значительной степени взаимозаменяемы. Однако SOAP всегда казался мне громоздким и чрезмерно сложным.

Затем появился REST, и вдруг веб-сервисы обрели смысл.

Как говорит Джоэл Спольски, дайте программисту URL-адрес REST, и он сможет сразу начать играть со службой, выяснив это.

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

Итак, суть моего вопроса:

• Есть ли веские причины когда-либо выбирать SOAP вместо REST?
• Вы сейчас работаете с SOAP? Было бы лучше, если бы интерфейс был REST?
• Я не прав?

Answer 1

Как говорит Джоэл Спольски, дайте программисту URL-адрес REST, и он сможет сразу начать играть со службой, выяснив это.

Если бы у службы был четко определенный, машиночитаемый контракт, то программисту не пришлось бы тратить время на его выяснение.

(не то, чтобы WSDL / SOAP обязательно являлся примером хорошей реализации хорошо определенного контракта, но в этом и был смысл WSDL)

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

Мне никогда не требовались детали обработки заголовков, когда я создавал сервисы SOAP в 2001 году. Это было до WSDL, и тогда было нормально использовать GET для получения информации и запросов (ничем не отличающихся от большинства приложений, которые утверждают, что они являются REST; REST имеет больше с точки зрения использования гиперссылок для обнаружения служб и POST с полезной нагрузкой SOAP для выполнения действий. Те действия, которые создали ресурсы, возвращали бы URL созданного ресурса клиенту, и клиент мог тогда ПОЛУЧИТЬ ресурс. Я думаю, это тот факт, что WSDL облегчает думать только с точки зрения RPC, а не действий, которые создают ресурсы, из-за которых SOAP теряет сюжет.

Answer 2

Проводя некоторое исследование, чтобы понять некоторые ответы здесь (особенно Джона Сондерса), я нашел этот пост http://harmful.cat -v.org / software / xml / soap / simple МЫЛО более безумно, чем я думал ...

Answer 3

На мой взгляд, SOAP может быть более «гибким», но в результате он слишком сложен (вы упомянули WSDL, который для меня всегда является камнем преткновения).

I get REST. Это просто . Единственный недостаток, который я могу заметить, это то, что вы ограничиваете себя этими четырьмя основными действиями против одного ресурса, которые могут не совсем соответствовать тому, как вы просматриваете свои данные.

Answer 4

Тема хорошо обсуждается в Почему мыло считается густым .

Answer 5

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

КСТАТИ. Следующим шагом после WSDL являются Семантические веб-сервисы .

Answer 6

Если вам не нужны функции протоколов серии WS- *; если вам не нужны услуги с самоописанием; если ваш сервис не может быть полностью описан как ресурсы, как определено протоколом HTTP; если вам не нравится создавать XML для каждого взаимодействия со службой, а затем анализировать его; тогда вам нужно SOAP.

В противном случае обязательно используйте REST.

---

Возник некоторый вопрос о ценности услуги с самоописанием. Мое воображение подводит меня, когда дело доходит до представления, как кто-то может не понять этого. Это на мне. Тем не менее, я должен думать, что любой, кто когда-либо использовал услугу, намного более сложную, чем «Hello, world», знал бы, почему так важно, чтобы кто-то еще написал код, который принимает параметры, создает XML для отправки в службу, отправляет он получает ответ, затем превращает его обратно в объекты.

Теперь, я полагаю, это может не понадобиться при использовании службы RESTful; по крайней мере, не с сервисом RESTful, который не обрабатывает сложные объекты. Даже с относительно простой службой, такой как http://www.earthtools.org/webservices.htm (которую я использовал в качестве примера вызова службы RESTful), можно понять структуру возвращаемых данных. Даже вышеуказанный сервис предоставляет XML-схему - к сожалению, он не описывает весь ответ. Принимая во внимание эту схему, все же необходимо вручную обработать XML или использовать инструмент для создания сериализуемых классов из схемы.

Все это происходит для вас, когда служба описана в WSDL, и вы используете такой инструмент, как «Добавить ссылку на службу» в Visual Studio, или программу svcutil.exe, или команду «я забуду, что за команда» -is-в-Затмения.

Если вам нужны примеры, начните со служб EarthTools и перейдите к любым другим службам с более сложным обменом сообщениями.

Кстати, еще одна вещь, которая требует самоописания - это описание шаблонов обмена сообщениями и протоколов, поддерживаемых службой. Возможно, это не требуется, когда единственными вариантами выбора являются HTTP-глаголы по HTTP или HTTPS. Жизнь становится сложнее, если вы используете WS-Security и друзей.

Answer 7

Что ж, теперь кажется, что WSI согласны с тем, что SOAP более не имеет смысла, поскольку они объявили, что прекратят свое существование как независимый объект.

Интересная статья об анонсе и некоторые комментарии здесь: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm

Отредактировано, чтобы быть полностью точным в ответ на Джона Сондерса.

Answer 8

Я считаю, что SOAP подходит наиболее подходящим образом, когда существует высокая вероятность того, что служба будет использоваться корпоративным программным обеспечением (COTS). Из-за четко определенного контракта, используемого SOAP / WSDL, большинство пакетов COTS имеют встроенную функциональность для использования таких сервисов. Это может облегчить BPM / инструментам рабочего процесса и т. Д. Просто использовать определенные сервисы без настройки. Помимо этого варианта использования службы REST, как правило, является моей реализацией веб-службы goto для приложений.

Answer 9

Я думаю, что SOAP привлекает толпу Java и .net, которые могут быть более знакомы со старыми CORBA и COM и менее знакомы с интернет-технологиями.

REST также имеет один существенный недостаток: очень мало указаний о том, как на самом деле реализовать такую ​​систему. Вы найдете значительные различия в том, сколько открытых API RESTful было разработано. Фактически многие нарушают ключевые аспекты REST (такие как использование GET для манипулирования или POST для извлечения), и существуют разногласия по поводу основного использования (POST / GET против POST / GET / PUT / DELETE).

Answer 10

SOAP - это облегченная спецификация структурированного протокола на основе XML, используемая при реализации сервисов. Используется для обмена структурированная информация в децентрализованной, распределенной среде. SOAP использует технологии XML для обмена информацией по любому протоколу транспортного уровня. Он не зависит от какой-либо конкретной модели программирования и другой конкретной семантики реализации. Узнайте больше о XML SOAP Messaging Framework

Основанная на XML структура обмена сообщениями, которая 1) Расширяемость: простота остается одной из основных целей разработки SOAP. SOAP определяет коммуникационную среду, которая обеспечивает такие функции, как безопасность, маршрутизация и надежность будет добавлена ​​позже, как слоистые расширения

2) Взаимодействующий: SOAP может использоваться через любой транспортный протокол, такой как TCP, HTTP, SMTP. SOAP обеспечивает явную привязку сегодня для HTTP.

3) Независимо: SOAP допускает любую модель программирования и не привязан к удаленному вызову процедур (RPC). SOAP определяет модель для обработки отдельных односторонних сообщений. SOAP также позволяет использовать любое количество шаблонов обмена сообщениями (MEP). Узнайте больше о SOAP