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

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

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

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

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

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

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

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

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

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

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

Сравните это, скажем, с API для твиттера . Это настоящий сервис 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 (если есть), когда вы хотите разоблачить данные, или потреблять или публиковать их, в качестве постоянного ресурса.

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

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

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