Различия в версиях SOAP
И SOAP версии 1.1, и SOAP версии 1.2 являются стандартами World Wide Web Consortium (W3C). Можно развернуть веб-сервисы, которые поддерживают не только SOAP 1.1, но и SOAP 1.2. Некоторые изменения в SOAP 1.1, внесенные в спецификацию SOAP 1.2, являются существенными, в то время как другие изменения незначительны.
Спецификация SOAP 1.2 вводит несколько изменений в SOAP 1.1. Эта информация не предназначена для подробного описания всех новых или измененных функций SOAP 1.1 и SOAP 1.2. Вместо этого эта информация подчеркивает некоторые из наиболее важных различий между текущими версиями SOAP.
Существенные изменения в спецификации SOAP 1.2 включают следующие обновления:
SOAP 1.1 основан на XML 1.0. SOAP 1.2 основан на информационном наборе XML (XML Infoset).
Информационный набор XML (infoset) предоставляет способ описания XML-документа с помощью схемы XSD. Однако информационный набор не обязательно сериализует документ с сериализацией XML 1.0, на которой основан SOAP 1.1. Этот новый способ описания документа XML помогает выявить другие форматы сериализации, такие как двоичный формат протокола. Вы можете использовать двоичный формат протокола для сжатия сообщения в компактный формат, где некоторая подробная информация о тегировании может не потребоваться.
В SOAP 1.2 вы можете использовать спецификацию привязки к базовому протоколу, чтобы определить, какая сериализация XML используется в блоках данных базового протокола. Привязка HTTP, указанная в SOAP 1.2 - часть 2, использует XML 1.0 в качестве сериализации информационного набора сообщений SOAP.
SOAP 1.2 предоставляет возможность официально определять транспортные протоколы, кроме использования HTTP, при условии, что поставщик соответствует структуре привязки, определенной в SOAP 1.2. Хотя HTTP является вездесущим, он не так надежен, как другие транспорты, включая TCP / IP и MQ.
SOAP 1.2 предоставляет более конкретное определение модели обработки SOAP, которая устраняет многие неопределенности, которые могут привести к ошибкам взаимодействия при отсутствии профилей взаимодействия веб-служб (WS-I). Цель состоит в том, чтобы значительно снизить вероятность проблем взаимодействия между различными поставщиками, которые используют реализации SOAP 1.2.
SOAP с Attachments API для Java (SAAJ) также может выступать в качестве простого механизма для выдачи запросов SOAP. Основным изменением в спецификации SAAJ является возможность представления сообщений SOAP 1.1 и дополнительных сообщений в формате SOAP 1.2. Например, SAAJ версии 1.3 представляет новый набор констант и методов, которые более благоприятны для SOAP 1.2 (например, getRole (), getRelay ()) для элементов заголовка SOAP. На фабриках SAAJ также существуют дополнительные методы для создания соответствующих сообщений SOAP 1.1 или SOAP 1.2.
Пространства имен XML для схем конверта и кодирования изменены для SOAP 1.2. Эти изменения отличают процессоры SOAP от сообщений SOAP 1.1 и SOAP 1.2 и поддерживают изменения в схеме SOAP, не затрагивая существующие реализации.
Архитектура Java для веб-служб XML (JAX-WS) предоставляет возможность поддержки как SOAP 1.1, так и SOAP 1.2. Поскольку JAX-RPC ввел требование манипулировать сообщением SOAP при его прохождении во время выполнения, возникла необходимость представить это сообщение в соответствующем контексте SOAP. В JAX-WS ряд дополнительных улучшений стал результатом поддержки SAAJ 1.3.
Не существует метода POST AND GET для конкретного андроида .... но здесь есть разница
GET
Метод GET добавляет пары URL / имя в URL, что позволяет вам получить представление ресурса. Большая проблема в этом заключается в том, что длина URL-адреса ограничена (примерно 3000 символов), что приводит к потере данных, если вам придется заполнять форму в вашей странице, поэтому этот метод работает только при небольшом количестве параметров.
Что это значит для меня?В основном это делает метод GET бесполезным для большинства разработчиков в большинстве ситуаций.Вот еще один способ взглянуть на это: URL-адрес может быть усечен (и, скорее всего, он даст сегодняшние сайты, ориентированные на данные), если форма использует большое количество параметров или если параметры содержат большие объемы данных.Кроме того, параметры, передаваемые по URL, видны в поле адреса браузера (YIKES !!!), не лучшее место для показа любых чувствительных (или даже нечувствительных) данных, поскольку вы просто просите любопытного пользователявозиться с этим.
POST Альтернативой методу GET является метод POST.Этот метод упаковывает пары имя / значение внутри тела HTTP-запроса, что делает URL-адрес более чистым и не накладывает ограничений на размер выходных данных форм, в основном это не составляет никакого труда для использования.POST также более безопасен, но, безусловно, небезопасен.Хотя HTTP полностью поддерживает CRUD, HTML 4 поддерживает только выдачу запросов GET и POST через его различные элементы.Это ограничение удерживает веб-приложения от полного использования HTTP, и, чтобы обойти его, большинство приложений перегружают POST, чтобы заботиться обо всем, кроме поиска ресурсов.
Ссылка на исходный источник IBM