Quelle est la différence entre SOAP 1.1, SOAP 1.2, HTTP GET & HTTP POST méthodes pour Android?

Différences dans la fabrication de SAVON versions

Les deux Version SOAP 1.1 et SOAP Version 1.2 sont World Wide Web Consortium (W3C) des normes. Les services Web peuvent être déployés pour soutenir non seulement SOAP 1.1, mais aussi de support de SOAP 1.2. Certains changements de SOAP 1.1 qui ont été faites pour le SOAP 1.2 cahier des charges sont importantes, tandis que d'autres changements sont mineurs.

Le SOAP 1.2 de la spécification introduit plusieurs modifications pour SOAP 1.1. Cette information n'est pas destinée à être une description en profondeur de tous les nouveaux ou modifiés caractéristiques de SAVON SOAP 1.1 et 1.2. Au lieu de cela, cette information met en évidence certaines des plus importantes différences entre les versions actuelles de SAVON.

Les modifications apportées à la SOAP 1.2 spécifications qui sont importants comprennent les mises à jour suivantes:
SOAP 1.1 est basé sur XML 1.0. SOAP 1.2 est basé sur XML Information Set (XML Infoset).
Le XML information set (infoset) fournit une manière de décrire le document XML avec un schéma XSD. Toutefois, les informations ne sont pas nécessairement sérialiser le document XML 1.0 sérialisation sur lequel SOAP 1.1 est basé.. Cette nouvelle façon de décrire le document XML permet de révéler d'autres formats de sérialisation, tel qu'un protocole binaire format. Vous pouvez utiliser le protocole binaire format compact le message dans un format compact, où quelques-uns des prolixe informations de marquage pourrait ne pas être nécessaire.

Dans SOAP 1.2 , vous pouvez utiliser le cahier des charges d'une liaison à un protocole sous-jacent pour déterminer la sérialisation XML est utilisé dans le protocole sous-jacent unités de données. La liaison HTTP qui est spécifié dans le SOAP 1.2 - Partie 2 utilise XML 1.0 comme la sérialisation du message SOAP infoset.

SOAP 1.2 offre la possibilité de définir officiellement les protocoles de transport, autres que l'aide de HTTP, aussi longtemps que le fournisseur se conforme au cadre contraignant qui est défini dans le SOAP 1.2. Alors que HTTP est omniprésente, elle n'est pas aussi fiable que d'autres moyens de transport, y compris le protocole TCP/IP et de la MQ.
SOAP 1.2 fournit une définition plus spécifique de la SAVON de modèle de traitement qui supprime bon nombre d'ambiguïtés qui pourraient conduire à l'interopérabilité des erreurs en l'absence des Services Web Interoperability (WS-I) les profils. L'objectif est de réduire considérablement les risques de problèmes d'interopérabilité entre les différents fournisseurs que l'utilisation de SOAP 1.2 implémentations.
SAVON avec des pièces Jointes de l'API Java (SAAJ) peut aussi être utilisée seule comme un simple mécanisme d'émettre des requêtes SOAP. Un changement majeur pour la SAAJ spécification est la capacité à représenter les messages SOAP 1.1 et le supplément de SOAP 1.2 messages formatés. Par exemple, SAAJ Version 1.3 introduit un nouvel ensemble de constantes et de méthodes qui sont plus propices à l'SOAP 1.2 (comme getRole(), getRelay()) sur les éléments d'en-tête SOAP. Il existe aussi d'autres méthodes sur le usines pour SAAJ à créer des SOAP 1.1 ou SOAP 1.2 messages.
Les espaces de noms XML pour l'enveloppe et les schémas d'encodage ont été modifiés pour la SOAP 1.2. Ces changements distinguer SAVON processeurs de SAVON SOAP 1.1 et 1.2 messages et prend en charge les changements dans le schéma SOAP, sans affecter les implémentations existantes.
Java Architecture for XML Web Services (JAX-WS) introduit la possibilité de soutenir à la fois le SAVON SOAP 1.1 et 1.2. Parce que JAX-RPC a introduit une obligation de manipuler un message SOAP comme il traversées par la course du temps, il est devenu nécessaire de représenter ce message dans son SAVON contexte. Dans JAX-WS, un certain nombre d'améliorations supplémentaires résultant de l'appui pour SAAJ 1.3.

Il n'y a pas difine POST ET GET méthode pour particulier android....mais tout ici est différance

OBTENIR
La méthode GET ajoute des paires nom/valeur de l'URL, vous permettant de récupérer une ressource de la représentation. Le gros problème, c'est que la longueur d'une URL est limitée (environ 3000 char) résultant en la perte de données si vous avez beaucoup de choses dans le formulaire sur votre page, si cette méthode ne fonctionne que si il y a un petit nombre de paramètres.

Qu'est-ce que cela signifie pour moi? En gros, cela rend la méthode GET pas de valeur pour la plupart des développeurs dans la plupart des situations. Voici une autre façon de voir les choses: l'URL pourrait être tronqué (et le plus probable sera de donner aujourd'hui centrée sur les données, sites) si le formulaire utilise un grand nombre de paramètres, ou si les paramètres contiennent de grandes quantités de données. Aussi, les paramètres passés dans l'URL sont visibles dans le champ adresse du navigateur (AÏE!!!) pas le meilleur endroit pour tout type sensible (ou même non-sensibles) les données présentées parce que vous êtes juste à la mendicité les curieux de l'utilisateur de jouer avec ça.

POST
L'alternative à la méthode GET est la méthode POST. Cette méthode paquets les paires nom/valeur à l'intérieur du corps de la requête HTTP, ce qui rend pour une URL de décapant et n'impose pas de restrictions de taille sur les formulaires de sortie, fondamentalement, de son une évidence sur laquelle utiliser. La POSTE est également plus sûre, mais certainement pas à l'abri. Bien que HTTP soutient pleinement CRUD, HTML 4 prend uniquement en charge la délivrance de GET et POST demandes par le biais de ses différents éléments. Cette limitation a occupé des applications Web de retour de la pleine utilisation de HTTP, et de travailler autour d'elle, la plupart des applications de surcharge POST pour prendre soin de tout, mais la récupération de ressource.

Lien original IBM source