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

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

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

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

...и так далее. Этот список не является исчерпывающим. То, что WSDL добавляет к SOAP, в первую очередь:

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

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

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

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

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

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

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

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

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

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

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

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

надеюсь, что это проясняет некоторые путаницы.