Je travaille sur un code pour les services Web SOAP. J'aimerais connaître les variations des méthodes SOAP 1.1, SOAP 1.2, HTTP GET et HTTP POST pour Android, et savoir quelle est la méthode préférée parmi elles. Veuillez m'indiquer un exemple d'URL d'utilisation ou son code.
Merci
Différences entre les versions de SOAP
SOAP version 1.1 et SOAP version 1.2 sont toutes deux des normes du World Wide Web Consortium (W3C). Il est possible de déployer des services Web qui prennent en charge non seulement SOAP 1.1 mais aussi SOAP 1.2. Certaines modifications apportées à la spécification SOAP 1.2 par rapport à SOAP 1.1 sont importantes, tandis que d'autres sont mineures.
La spécification SOAP 1.2 introduit plusieurs changements par rapport à SOAP 1.1. Ces informations n'ont pas pour but d'être une description approfondie de toutes les fonctionnalités nouvelles ou modifiées de SOAP 1.1 et SOAP 1.2. Au lieu de cela, ces informations soulignent certaines des différences les plus importantes entre les versions actuelles de SOAP.
Les modifications de la spécification SOAP 1.2 qui sont significatives comprennent les mises à jour suivantes : SOAP 1.1 est basé sur XML 1.0. SOAP 1.2 est basé sur l'ensemble d'informations XML (Infoset). L'ensemble d'informations XML (infoset) fournit un moyen de décrire le document XML avec le schéma XSD. Cependant, l'infoset ne sérialise pas nécessairement le document avec la sérialisation XML 1.0 sur laquelle 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, tels qu'un format de protocole binaire. Vous pouvez utiliser le format de protocole binaire pour compacter le message dans un format compact, où certaines des informations de balisage verbeuses peuvent ne pas être nécessaires.
Dans SOAP 1.2 , vous pouvez utiliser la spécification d'une liaison à un protocole sous-jacent pour déterminer quelle sérialisation XML est utilisée dans les unités de données du protocole sous-jacent. La liaison HTTP spécifiée dans SOAP 1.2 - Partie 2 utilise XML 1.0 comme sérialisation de l'ensemble d'informations du message SOAP.
SOAP 1.2 offre la possibilité de définir officiellement des protocoles de transport autres que HTTP, à condition que le fournisseur se conforme au cadre de liaison défini dans SOAP 1.2. Bien que HTTP soit omniprésent, il n'est pas aussi fiable que d'autres transports comme TCP/IP et MQ. SOAP 1.2 fournit une définition plus spécifique du modèle de traitement SOAP qui lève de nombreuses ambiguïtés susceptibles d'entraîner des erreurs d'interopérabilité en l'absence des profils d'interopérabilité des services Web (WS-I). L'objectif est de réduire considérablement les risques de problèmes d'interopérabilité entre les différents fournisseurs qui utilisent des implémentations SOAP 1.2. SOAP with Attachments API for Java (SAAJ) peut également être utilisé seul comme mécanisme simple pour émettre des requêtes SOAP. L'un des principaux changements apportés à la spécification SAAJ est la possibilité de représenter les messages SOAP 1.1 et les messages supplémentaires au format SOAP 1.2. Par exemple, la version 1.3 de SAAJ introduit un nouvel ensemble de constantes et de méthodes qui sont plus favorables à SOAP 1.2 (telles que getRole(), getRelay()) sur les éléments d'en-tête SOAP. Il existe également des méthodes supplémentaires sur les fabriques pour que SAAJ crée des messages SOAP 1.1 ou SOAP 1.2 appropriés. Les espaces de noms XML pour les schémas d'enveloppe et d'encodage ont été modifiés pour SOAP 1.2. Ces changements permettent de distinguer les processeurs SOAP des messages SOAP 1.1 et SOAP 1.2 et de prendre en charge les modifications du schéma SOAP, sans affecter les implémentations existantes. Java Architecture for XML Web Services (JAX-WS) introduit la possibilité de prendre en charge à la fois SOAP 1.1 et SOAP 1.2. Comme JAX-RPC a introduit la nécessité de manipuler un message SOAP lors de son passage dans le temps d'exécution, il est devenu nécessaire de représenter ce message dans son contexte SOAP approprié. Dans JAX-WS, un certain nombre d'améliorations supplémentaires résultent de la prise en charge de SAAJ 1.3.
Il n'y a pas de méthode POST ET GET différente pour chaque Android.... mais tout ici est différent.
GET La méthode GET ajoute des paires nom/valeur à l'URL, ce qui vous permet de récupérer la représentation d'une ressource. Le gros problème avec cette méthode est que la longueur d'une URL est limitée (environ 3000 caractères), ce qui entraîne une perte de données si vous avez trop d'éléments dans le formulaire de votre page. Cette méthode ne fonctionne donc que si le nombre de paramètres est faible.
Qu'est-ce que cela signifie pour moi ? En gros, cela rend la méthode GET inutile pour la plupart des développeurs dans la plupart des situations. Voici une autre façon de voir les choses : l'URL peut être tronquée (et le sera très probablement sur les sites actuels centrés sur les données) si le formulaire utilise un grand nombre de paramètres ou si les paramètres contiennent de grandes quantités de données. En outre, les paramètres transmis par l'URL sont visibles dans le champ d'adresse du navigateur (YIKES !!!), ce qui n'est pas le meilleur endroit pour afficher des données sensibles (ou même non sensibles), car vous ne faites que supplier l'utilisateur curieux de les manipuler.
POST L'alternative à la méthode GET est la méthode POST. Cette méthode regroupe les paires nom/valeur dans le corps de la requête HTTP, ce qui donne une URL plus propre et n'impose aucune limite de taille à la sortie des formulaires. La méthode POST est également plus sûre, mais elle ne l'est certainement pas. Bien que HTTP prenne entièrement en charge le CRUD, HTML 4 ne prend en charge que l'émission de requêtes GET et POST par le biais de ses différents éléments. Cette limitation a empêché les applications Web d'utiliser pleinement HTTP et, pour la contourner, la plupart des applications surchargent POST pour s'occuper de tout sauf de la récupération des ressources.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
