МЫЛО - Какой смысл?
Я имею в виду, действительно, какой смысл SOAP?
Веб-сервисы существуют уже некоторое время, и какое-то время казалось, что термины "SOAP" и "веб-сервис" в значительной степени взаимозаменяемы. Однако SOAP всегда казался мне громоздким и чрезмерно сложным.
Затем появился REST, и вдруг веб-сервисы обрели смысл.
Как говорит Джоэл Спольски, дайте программисту URL-адрес REST, и он сразу же начнет играть со службой, выясняя это.
SOAP скрывается за WSDL и массивным многословным XML, и, несмотря на то, что он основан на сети, вы не можете сделать ничего более простого, чем получить доступ к службе SOAP через веб-браузер.
Так что суть моего вопроса такова:
- Есть ли веские причины когда-либо выбирать SOAP вместо REST?
- Вы сейчас работаете с SOAP? Было бы лучше, если бы интерфейс был REST?
- Я ошибся?
11 ответов
Похоже, теперь WSI согласна с тем, что SOAP более не имеет смысла, поскольку они объявили, что прекратят свое существование как независимый объект.
Интересная статья об объявлении и некоторые комментарии здесь: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm
Отредактировано, чтобы быть полностью точным в ответ на Джона Сондерса.
Как говорит Джоэл Спольски, дайте программисту URL-адрес REST, и он сразу же начнет играть со службой, выясняя это.
В то время как если бы сервис имел четко определенный, машиночитаемый контракт, то программисту не пришлось бы тратить время на его выяснение.
(не то, чтобы WSDL/SOAP обязательно являлся примером хорошей реализации хорошо определенного контракта, но в этом и был смысл WSDL)
Первоначально SOAP был простым протоколом, который позволял вам добавлять заголовок к сообщению, и имел стандартизированное отображение экземпляров объектов в структуры XML. Размещение метаданных обработки в сообщении упростило клиентский код и означало, что вы можете очень просто сохранять и помещать сообщения в очередь.
Мне никогда не требовались детали обработки заголовков, когда я создавал сервисы SOAP в 2001 году. Это было до WSDL, и тогда было нормально использовать GET для получения информации и запросов (ничем не отличается от большинства приложений, которые претендуют на то, чтобы быть REST; REST имеет больше с точки зрения использования гиперссылок для обнаружения служб) и POST с полезной нагрузкой SOAP для выполнения действий. Те действия, которые создали ресурсы, возвращали бы URL созданного ресурса клиенту, и клиент мог тогда ПОЛУЧИТЬ ресурс. Я думаю, это тот факт, что WSDL облегчает думать только с точки зрения RPC, а не действий, которые создают ресурсы, из-за которых SOAP теряет смысл.
Выполняя некоторые исследования, чтобы понять некоторые ответы здесь (особенно Джона Сандерса), я обнаружил этот пост http://harmful.cat-v.org/software/xml/soap/simple SOAP более безумно, чем я думал...
На мой взгляд, SOAP может быть более "гибким", но в результате он слишком сложен (вы упомянули WSDL, который для меня всегда является камнем преткновения).
Я получаю отдых. Все просто Единственный недостаток, который я могу видеть, это то, что вы ограничиваете себя этими четырьмя основными действиями против одного ресурса, которые могут не совсем соответствовать тому, как вы просматриваете свои данные.
Тема хорошо обсуждается в разделе Почему мыло считается густым.
Суть WSDL была в авто-обнаружении. Идея заключалась в том, что вам не нужно писать код клиента, он будет сгенерирован автоматически.
КСТАТИ. Следующим шагом после WSDL являются Semantic Web Services.
Если вам не нужны функции протоколов серии WS-*; если вам не нужны услуги с самоописанием; если ваш сервис не может быть полностью описан как ресурсы, как определено протоколом HTTP; если вам не нравится создавать XML для каждого взаимодействия со службой, а затем анализировать его; тогда вам нужно SOAP.
В противном случае, конечно, используйте REST.
Был некоторый вопрос о ценности самоописывающей услуги. Мое воображение подводит меня, когда дело доходит до представления, как кто-то может не понять этого. Это на мне. Тем не менее, я должен думать, что любой, кто когда-либо использовал услугу, намного более сложную, чем "Hello, world", знал бы, почему так важно, чтобы кто-то еще написал код, который принимает параметры, создает XML для отправки в службу, отправляет он получает ответ, затем превращает его обратно в объекты.
Теперь, я полагаю, это может не понадобиться при использовании сервиса RESTful; по крайней мере, не с сервисом RESTful, который не обрабатывает сложные объекты. Даже с относительно простым сервисом, таким как http://www.earthtools.org/webservices.htm (который я использовал в качестве примера вызова сервиса RESTful), можно понять структуру возвращаемых данных. Даже вышеуказанный сервис предоставляет XML-схему - к сожалению, он не описывает весь ответ. Принимая во внимание эту схему, по-прежнему приходится вручную обрабатывать XML или использовать инструмент для создания сериализуемых классов из схемы.
Все это происходит для вас, когда служба описывается в WSDL, и вы используете такой инструмент, как "Добавить ссылку на службу" в Visual Studio, или программу svcutil.exe, или "я забываю, что такое команда". в-Eclipse.
Если вам нужны примеры, начните со служб EarthTools и перейдите к любым другим службам с более сложным обменом сообщениями.
Кстати, еще одна вещь, которая требует самоописания, - это описание шаблонов обмена сообщениями и протоколов, поддерживаемых службой. Возможно, это не требуется, когда единственными вариантами выбора являются HTTP-глаголы по HTTP или HTTPS. Жизнь становится сложнее, если вы используете WS-Security и друзей.
Я считаю, что SOAP наиболее подходит, когда существует высокая вероятность того, что сервис будет использоваться корпоративным программным обеспечением (COTS). Из-за четко определенного контракта, используемого SOAP/WSDL, большинство пакетов COTS имеют встроенную функциональность для использования таких сервисов. Это может облегчить BPM/ инструментам рабочего процесса и т. Д. Простое использование определенных сервисов без настройки. Помимо этого варианта использования службы REST является моей реализацией веб-службы goto для приложений.
Я думаю, что SOAP привлекает толпу Java и.net, которые могут быть более знакомы со старыми CORBA и COM и менее знакомы с интернет-технологиями.
У REST также есть один существенный недостаток: очень мало указаний о том, как на самом деле реализовать такую систему. Вы найдете значительные различия в том, сколько открытых API RESTful было разработано. Фактически многие нарушают ключевые аспекты REST (такие как использование GET для манипулирования или POST для извлечения), и существуют разногласия по поводу основного использования (POST/GET против POST/GET/PUT/DELETE).
Я ошибся?
"Ты не ошибаешься, Уолтер, ты просто...:)"
Есть ли веские причины когда-либо выбирать SOAP вместо REST?
SOAP, насколько я понимаю, придерживается контракта, таким образом, может быть проверен тип.
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