Преимущества пар имя-значение для SOAP/WSDL

Похоже, что в этой отрасли существует бесконечная путаница в отношении различных типов веб-сервисов.

SOAP-это протокол обмена сообщениями . У него столько же общего с отдыхом, сколько у яблока с газонным трактором. Некоторые из вещей, которые вы хотите использовать в протоколе обмена сообщениями:

Заголовки и другие атрибуты, не относящиеся к контенту."
• адресация-маршрутизация сообщения к различным серверам / получателям на основе заголовков;
• гарантированная доставка через очередь и другие методы;
• шифрование, подпись и другие функции безопасности;
• транзакции и оркестровки;
• точное представление сложных структурированных данных в одном сообщении;

...и так далее. Это далеко не полный перечень. Что WSDL добавляет к SOAP, в первую очередь, это:

• Возможность обнаружения с помощью контракта , формы машиночитаемой "документации", которая точно сообщает потребителям, что требуется для отправки сообщения и позволяет автоматически генерировать прокси;

• Строгая, автоматизированная проверка схемы сообщений, так же, как XSD работает для XML.

REST-этоне протокол обмена сообщениями. Покой - это система ресурсов и действий. Это надежный выбор для многих архитектур по нескольким важным причинам, как указано в других ответах. Он также имеет мало отношения к услугам" NVP", таким как PayPal и flickr.

NVP API PayPal не является ОСТАЛЬНОЕ. Это альтернативный RPC-подобный протокол обмена сообщениями через HTTP POST для клиентов, которые не поддерживают или испытывают трудности с поддержкой SOAP. Это не мое мнение, это констатация факта. Одно из полей в НВП на самом деле METHOD. Этоясно словоблудие RPC. Взгляните на их API дляUpdateRecurringPaymentsProfile и попробуйте сказать мне, что это имеет смысл описывать как "ресурс". Это не ресурс, а средство. операция .

В случае PayPal, в частности, API "NVP" (HTTP POST) уступает API SOAP почти во всех отношениях. Он существует для потребителей, которые не могут использовать мыло. Если вы можете использовать его, вы определенно должны.

И я не обязательно буду бить PayPal за это. Я знаю, что многие люди колотили их за то, что они не собрали "правильный" RESTful API, но это не то, что я имею в виду. Не каждая служба в мире может быть точно описан с отдыхом. PayPal на самом деле не является ресурсо-ориентированной системой, это транзакционная система , поэтому я могу простить их архитекторов и разработчиков за то, что у них нет идеально элегантной архитектуры REST. Возможно, это спорный вопрос, но он не черно-белый. Я просто воспользуюсь системой мыла, если понадобится.

Сравните это, скажем, интерфейс Твиттера. Это настоящая служба отдыха. Каждая "операция", которую вы можете выполнить с этим API, точно описывается как извлечение или передача определенного вида ресурсов. Ресурс - это твит, статус, пользователь. В этом случае буквально нет смысла использовать сложный SOAP API, потому что вы на самом деле не посылаете сообщения, вы не выполняете транзакции, вы просто просите определенные вещи, и эти вещи могут быть описаны с помощью одного URL. Единственная разница заключается в том, что вместо того, чтобы получить веб-страницу HTML, вы получаете некоторые данные XML или JSON; то, как вы просите, совершенно то же самое.

Веб-служба REST обычно (всегда?) использует HTTP GET для извлечения некоторого ресурса. И Twitter делает именно это. GET по-прежнему использует "пары имя - значение" - это строка запроса, ?q=twitterapi&show_user=true. Эти биты после ? являются парами имя-значение. И вот отличный пример того, почему вы хотите использовать REST поверх SOAP; вы можете подключить его к RSS-каналу и получать потоковые обновления. Я могу превратить его в живую закладку в Firefox. Или я могу скачать это в формате JSON и привязать его к чему-то вроде jqGrid. Интересно не то, что запрос использует "пары имя-значение"; интересно то, что это простой URL-адрес и может быть использован любым, кто знает, как запросить веб-страницу.

Итак, чтобы попытаться суммировать все, что я сказал, Подумайте об этом следующим образом:

• Используйте REST API (если он доступен), когда вы хотите предоставить данные, использовать или опубликовать их в качестве постоянного ресурса.

• Используйте мыло API, когда система транзакционна по своей природе и / или когда вам нужны дополнительные функции, которые может предложить сложный протокол обмена сообщениями, такие как RM и адресация.

• Используйте API RPC (который включает почти любой API, полностью смоделированный вокруг HTTP POST), когда нет API SOAP или когда вы не можете использовать API SOAP.

Надеюсь, это немного прояснит путаницу.