Jaka jest różnica między metodami SOAP 1.1, SOAP 1.2, HTTP GET i HTTP POST dla Androida?

Question

Pracuję nad kodem dla usług sieciowych SOAP, chciałbym znać różnice w SOAP 1.1, SOAP 1.2, HTTP GET & Metody HTTP POST dla systemu Android, i który jest preferowany wśród nich. Zapoznaj się z próbką jego adresu URL lub kodu.

Dzięki

Answer 1

różnice w wersjach SOAP

Zarówno SOAP w wersji 1.1 i SOAP w wersji 1.2 jest World Wide Web Consortium (W3C) normy. Można wdrożyć usługi sieci Web, które obsługują nie tylko protokół SOAP 1.1, ale także obsługują protokół SOAP 1.2. Niektóre zmiany z protokołu SOAP 1.1, które zostały wprowadzone do specyfikacji SOAP 1.2, są znaczące, natomiast inne zmiany są niewielkie.

W specyfikacji SOAP 1.2 wprowadzono kilka zmian w protokole SOAP 1.1. Informacje te nie stanowią wyczerpującego opisu wszystkich nowych lub zmienionych funkcji SOAP 1.1 i SOAP 1.2. Zamiast tego informacje te podkreślają niektóre z ważniejszych różnic między aktualnymi wersjami SOAP.

Zmiany w specyfikacji SOAP 1.2, które są znaczące obejmują następujące aktualizacje: SOAP 1.1 jest oparty na XML 1.0. SOAP 1.2 jest oparty na zestawie informacji XML (XML Infoset). Zestaw informacji XML (infoset) umożliwia opisanie dokumentu XML za pomocą schematu XSD. Jednak zbiór informacji nie musi serializować dokumentu z serializacją XML 1.0, na której oparte jest SOAP 1.1. Ten nowy sposób opisu dokumentu XML pomaga ujawnić inne formaty serializacji, takie jak format protokołu binarnego. Można użyć formatu protokołu binarnego, aby skompaktować komunikat w kompaktowy format, w którym niektóre szczegółowe informacje dotyczące oznaczania mogą nie być wymagane.

W SOAP 1.2 można użyć specyfikacji powiązania z bazowym protokołem, aby określić, która serializacja XML jest używana w podstawowych jednostkach danych protokołu. Powiązanie HTTP określone w SOAP 1.2 - Część 2 używa XML 1.0 jako serializacji komunikatu SOAP.

SOAP 1.2 zapewnia możliwość oficjalnego definiowania protokołów transportowych, innych niż przy użyciu protokołu HTTP, o ile dostawca jest zgodny z ramą wiążącą zdefiniowaną w SOAP 1.2. Chociaż HTTP jest wszechobecny, nie jest tak niezawodny jak inne transporty, w tym TCP/IP i MQ. SOAP 1.2 zawiera bardziej szczegółową definicję modelu przetwarzania SOAP, który usuwa wiele niejednoznaczności, które mogą prowadzić do błędów w zakresie interoperacyjności w przypadku braku profili Web Services-Interoperability (WS-I). Celem jest znaczne zmniejszenie szans na problemy z interoperacyjnością między różnymi dostawcami używającymi implementacji SOAP 1.2. SOAP z dodatkami API dla Java (SAAJ) może również działać samodzielnie jako prosty mechanizm do wysyłania żądań SOAP. Główną zmianą w specyfikacji SAAJ jest możliwość reprezentowania komunikatów SOAP 1.1 i dodatkowych komunikatów w formacie SOAP 1.2. Na przykład, SAAJ wersja 1.3 wprowadza nowy zestaw stałych i metod, które bardziej sprzyjają SOAP 1.2 (takich jak getRole(), getRelay()) na elementach nagłówka SOAP. W fabrykach SAAJ istnieją również dodatkowe metody tworzenia odpowiednich komunikatów SOAP 1.1 lub SOAP 1.2. Przestrzenie nazw XML dla schematów kopert i kodowania zostały zmienione dla SOAP 1.2. Zmiany te odróżniają procesory SOAP od komunikatów SOAP 1.1 i SOAP 1.2 i obsługują zmiany w schemacie SOAP bez wpływu na istniejące implementacje. Architektura Java dla usług sieciowych XML (JAX-WS) wprowadza możliwość obsługi zarówno SOAP 1.1, jak i SOAP 1.2. Ponieważ JAX-RPC wprowadził wymóg manipulowania komunikatem SOAP podczas jego pracy w czasie wykonywania, pojawiła się potrzeba reprezentowania tego komunikatu w odpowiednim kontekście SOAP. W JAX-WS wiele dodatkowych ulepszeń wynika ze wsparcia dla SAAJ 1.3.

nie ma difine POST i GET metodę szczególności android .... ale wszystko tutaj jest differance

GET Metoda GET dołącza pary nazwa/wartość do adresu URL, dzięki czemu można odzyskać zasobu reprezentacja. Dużym problemem jest to, że długość adresu URL jest ograniczona (około 3000 znaków), co powoduje utratę danych w przypadku dużej ilości elementów w formularzu na stronie, więc ta metoda działa tylko w przypadku małych parametrów liczbowych.

Co to oznacza dla mnie? Zasadniczo czyni to metodę GET bezwartościową dla większości programistów w większości sytuacji. Oto inny sposób patrzenia na to: adres URL może zostać skrócony (i najprawdopodobniej będzie to dawać dzisiejsze witryny zorientowane na dane), jeśli formularz będzie zawierał dużą liczbę parametrów lub jeśli parametry zawierają duże ilości danych. Ponadto parametry przekazane na adres URL są widoczne w polu adresu przeglądarki (YIKES !!!), a nie najlepszym miejscu dla każdego wrażliwego (lub nawet niewrażliwego) danych, które mają być wyświetlane, ponieważ dopiero co błagasz ciekawy użytkownik bałagan z tym.

PO Alternatywą dla metody GET jest metoda POST. Ta metoda pakuje pary nazwa/wartość wewnątrz treści żądania HTTP, co powoduje, że adres URL jest czystszy i nie nakłada żadnych ograniczeń rozmiaru na dane wyjściowe formularzy, w zasadzie nie jest to żaden element, którego można użyć. POST jest również bezpieczniejszy, ale z pewnością nie jest bezpieczny. Chociaż HTTP w pełni obsługuje CRUD, HTML 4 obsługuje tylko żądania GET i POST za pośrednictwem różnych elementów. To ograniczenie powstrzymuje aplikacje internetowe przed pełnym wykorzystaniem HTTP i obejściem go, większość aplikacji obciąża POST, aby zająć się wszystkim oprócz pobierania zasobów.

Link to original IBM source

Answer 2

Po dokumentu opublikowanego przez W3C opisuje również różnice między SOAP 1.1 i 1.2:

• From SOAP/1.1 to SOAP Version 1.2 in 9 points