В чем разница между SOAP 1.1, SOAP 1.2, HTTP GET и HTTP POST-методами для Android?

Я работаю над кодом для веб-сервисов SOAP, я хотел бы знать изменения в методах SOAP 1.1, SOAP 1.2, HTTP GET и HTTP POST для Android, и который является предпочтительным среди них. Пожалуйста, разместите образец URL-адреса его использования или его кода.

Спасибо

Ответ 1

Различия в версиях SOAP

Оба SOAP версии 1.1 и SOAP версии 1.2 являются стандартами консорциума World Wide Web (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 (информационный) предоставляет способ описания XML-документа с помощью схемы XSD. Тем не менее, infoset не обязательно сериализует документ с сериализацией XML 1.0, на которой основан SOAP 1.1. Этот новый способ описания документа XML помогает выявить другие форматы сериализации, такие как формат двоичного протокола. Вы можете использовать формат бинарного протокола для компактного сообщения в компактном формате, где некоторая часть подробной информации тегов может не потребоваться.

В SOAP 1.2 вы можете использовать спецификацию привязки к базовому протоколу, чтобы определить, какая сериализация XML используется в базовых единицах данных протокола. Связывание HTTP, указанное в SOAP 1.2 - Part 2, использует XML 1.0 как сериализацию информационного сообщения SOAP.

SOAP 1.2 предоставляет возможность официально определять транспортные протоколы, кроме использования HTTP, до тех пор, пока поставщик соответствует структуре привязки, которая определена в SOAP 1.2. Хотя HTTP вездесущ, он не так надежен, как другие транспортные средства, включая TCP/IP и MQ. SOAP 1.2 предоставляет более конкретное определение модели обработки SOAP, которая устраняет многие неоднозначности, которые могут привести к ошибкам совместимости при отсутствии профилей Web-совместимости (WS-I). Цель состоит в том, чтобы значительно снизить шансы на совместимость между различными поставщиками, использующими реализации SOAP 1.2. SOAP с 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 и GET для конкретного андроида.... но все здесь различие

GET Метод GET присоединяет пары имени/значения к URL-адресу, что позволяет получить представление ресурса. Большая проблема заключается в том, что длина URL-адреса ограничена (примерно 3000 char), что приводит к потере данных, если вам нужно много материала в форме на вашей странице, поэтому этот метод работает только при наличии небольшого числа параметров,

Что это значит для меня? В основном это делает метод GET бесполезным для большинства разработчиков в большинстве ситуаций. Вот еще один способ взглянуть на это: URL-адрес может быть усечен (и, скорее всего, будет давать сегодня сайты, ориентированные на данные), если форма использует большое количество параметров или если параметры содержат большие объемы данных. Кроме того, параметры, переданные по URL-адресу, видны в поле адреса браузера (YIKES!!!), не лучшее место для отображения любых чувствительных (или даже не чувствительных) данных, потому что вы просто попрошайничать любопытного пользователя чтобы с ним справиться.

POST Альтернативой методу GET является метод POST. Этот метод упаковывает пары имя/значение внутри тела HTTP-запроса, что делает более чистый URL-адрес и не налагает ограничений по размеру выходных данных форм, в основном его отсутствие, на котором можно использовать. POST также более безопасен, но, безусловно, небезопасен. Хотя HTTP полностью поддерживает CRUD, HTML 4 поддерживает только выдачу запросов GET и POST через различные элементы. Это ограничение вернуло веб-приложения от полного использования HTTP и для его работы, большинство приложений перегружают POST, чтобы заботиться обо всем, кроме поиска ресурсов.

http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.wsfep.multiplatform.doc%2Finfo%2Fae%2Fae%2Fcwbs_soapverdiffs.html