SOAP - Какой смысл?

Как Joel Spolsky говорит, дайте программисту URL REST, и они могут начать играть с сервисом сразу же, поняв это.

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

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

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

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

Путем я вижу его, SOAP мог бы быть более "гибким", но в результате это только что слишком усложнило (Вы упомянули WSDL, который всегда является камнем преткновения для меня лично).

Я получаю REST. Это просто. Единственный недостаток, который я мог бы видеть, - то, что Вы ограничиваете себя теми 4 основными действиями против единственного ресурса, который не мог бы точно соответствовать способу, которым Вы просматриваете свои данные.

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

При проведении некоторого исследования для понимания некоторых ответов здесь (особенно John Saunders) я нашел это сообщение http://harmful.cat-v.org/software/xml/soap/simple, SOAP более безумен, чем я думал...

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

BTW. затем ступают вне WSDL, Семантические веб-сервисы.

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

Иначе, уверенный, используйте REST.

Был некоторый вопрос об уровне спроса самоописания. Мое воображение приводит меня к сбою когда дело доходит до воображения, как любой мог не понять это. Это находится на мне. Однако, я должен думать, что любой, кто когда-либо использовал сервис, намного более сложный, чем "Привет, мир", знал бы, почему ценно сделать, чтобы кто-то еще написал код, который принимает параметры, создает XML для отправки в службу, отправляет его, получает ответ, затем поворачивается спиной в объекты.

Теперь, я предполагаю, что это не могло бы быть необходимо при использовании УСПОКОИТЕЛЬНОГО сервиса; по крайней мере, не с УСПОКОИТЕЛЬНЫМ сервисом, который не обрабатывает сложные объекты. Даже с относительно простым сервисом как http://www.earthtools.org/webservices.htm (который я использовал в качестве примера вызова УСПОКОИТЕЛЬНОГО сервиса), каждый извлекает выгоду из понимания структуры возвращенных данных. Даже вышеупомянутый сервис предоставляет XML-схему - он, к сожалению, не описывает весь ответ. Учитывая, что схема все еще нужно вручную обработать XML или иначе использовать инструмент для создания сериализуемых классов из схемы.

Все это происходит для Вас, когда сервис описан в WSDL, и Вы используете инструмент как то, "Добавьте Сервисная Ссылка" в Visual Studio, или программе svcutil.exe или I-forget-what-the-command-is-in-Eclipse.

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

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

Я неправ?

"Вы не ошибаетесь, Walter, Вы просто... :)"

Там какие-либо серьезные основания состоят в том, чтобы когда-либо выбирать SOAP over REST?

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

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

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

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