В этой отрасли, похоже, существует бесконечная путаница с различными типами веб-сервисов.
SOAP - это протокол обмена сообщениями . Он имеет столько же общего с REST, сколько яблоко с газонным трактором. Вот некоторые вещи, которые вы хотите использовать в протоколе обмена сообщениями:
- Заголовки и другие не связанные с содержимым атрибуты.
- Адресация - маршрутизация сообщения различным серверам / получателям на основе заголовков;
- Гарантированная доставка через очереди и другими способами;
- Шифрование, подпись и другие функции безопасности;
- Транзакции и оркестровки;
- Точное представление сложных структурированных данных в одном сообщении;
... и так далее. Это не исчерпывающий список. WSDL добавляет, прежде всего, к SOAP:
Обнаруживаемость через контракт , форму машиночитаемой «документации», которая точно сообщает потребителям, что требуется для отправки сообщения, и позволяет автоматически генерировать прокси;
Строгая, автоматическая проверка схемы сообщений, точно так же, как XSD работает для XML.
REST - это , а не протокол обмена сообщениями. REST - это система ресурсов и действий . Это хороший выбор для многих архитектур по нескольким важным причинам, указанным в других ответах. Он также не имеет никакого отношения к службам «NVP», таким как PayPal и flickr.
API PayPal NVP не является REST. Это альтернативный RPC-подобный протокол обмена сообщениями по HTTP POST для клиентов, которые не поддерживают или испытывают трудности с поддержкой SOAP. Это не мое мнение, это констатация факта. Одно из полей в NVP на самом деле METHOD. Это явно RPC verbiage. Взгляните на их API для UpdateRecurringPaymentsProfile и попробуйте сказать мне, что это имеет смысл описать как «ресурс». Это не ресурс, это операция .
В частности, в случае PayPal API «NVP» (HTTP POST) почти полностью уступает API SOAP. Это для потребителей, которые не могут использовать SOAP. Если вы можете использовать его, вы определенно должны .
И я тоже не обязательно бить за это PayPal. Я знаю, что многие люди избили их за то, что они не создали «правильный» RESTful API, но это не то, к чему я стремлюсь. Не все услуги в мире могут быть точно описаны с помощью REST. PayPal на самом деле не система, основанная на ресурсах, это транзакционная система, поэтому я могу простить их архитекторам и разработчикам за то, что они не имеют совершенно элегантной архитектуры REST. Это спорный вопрос, возможно, но это не черно-белый. Все в порядке; Я просто использую систему SOAP, если мне нужно.
Сравните это, скажем, с Twitter API . Это настоящий REST сервис. Каждая «операция», которую вы можете выполнить с этим API, точно описывается как извлечение или передача ресурса определенного типа. Ресурс - это твит, статус, пользователь. В этом случае буквально не имеет смысла использовать сложный SOAP API, потому что вы на самом деле не отправляете сообщения , вы не выполняете транзакций , вы просто запрашиваете конкретные вещей , и эти вещей могут быть описаны с помощью одного URL. Единственное отличие состоит в том, что вместо возврата веб-страницы HTML вы получаете данные XML или JSON; способ, которым вы запрашиваете, точно такой же.
Веб-служба REST обычно (всегда?) Использует HTTP GET для получения какого-либо ресурса. И Twitter делает именно это. GET по-прежнему использует «пары имя-значение» - это строка запроса, ?q=twitterapi&show_user=true. Эти биты после ? являются парами имя-значение. И вот отличный пример того, почему вы хотите использовать REST поверх SOAP; Вы можете подключить это к RSS-каналу и получать потоковые обновления. Я могу превратить его в Live Bookmark в Firefox. Или я могу скачать его в формате JSON и связать с чем-то вроде jqGrid. Интересно не то, что в запросе используются «пары имя-значение»; Интересно то, что это простой URL-адрес и может использоваться любым, кто знает, как запросить веб-страницу.
Итак, чтобы попытаться обобщить все, что я сказал, подумайте об этом так:
Используйте REST API (если доступен), когда вы хотите предоставить данные или использовать или публиковать их как постоянный ресурс.
Используйте SOAP API, когда система носит транзакционный характер и / или когда вам нужны расширенные функции, которые может предложить сложный протокол обмена сообщениями, такие как RM и адресация.
Используйте API-интерфейс RPC (который включает в себя практически любой API-интерфейс, полностью смоделированный по протоколу HTTP POST), если API-интерфейс SOAP отсутствует или вы не можете использовать API-интерфейс SOAP.
Надеюсь, что это прояснит некоторые вопросы.