C'est surtout que les web services utilisent en principe les infrastructures du Web côté serveur, dans le sens où ils sont accessibles sur des ports connus et en utilisant les protocoles habituels (HTTP). Ceci les rend facilement accessibles depuis les réseaux d'entreprises, par exemple, en général très sécurisés et très filtrés, même depuis l'intérieur. L'avantage est que l'on utilise les mêmes couches sous-jacentes et que le XML est analysable relativement facilement. Cela évite de définir un protocole et d'accaparer un port par type de service rendu.
Ceci est associé au fait que SOAP est censé transmettre des objets, ce qui est appréciable dans le contexte actuel et lorsque les infrastructures pour gérer pleinement ce protocole sont déjà disponibles, par exemple en Java. C'est pour cela aussi que SOAP est souvent utilisé pour faire communiquer deux composants d'un même produit mais complètement distincts, par exemple un noyau en C et un GUI en Java, ceci faute de mieux parce que les protocoles d'échange d'objets pleinement aboutis, universels, libres et qui soient largement pris en charge ne sont pas légion.
Donc, c'est pratique pour mettre en place un backend public devant être exploité par des applications plutôt par l'utilisateur directement. Maintenant, ça a beaucoup d'inconvénients à l'usage également. Par exemple, c'est toujours pénible à gérer en C.
[^] # Re: Open Data
Posté par Obsidian . En réponse au message Un « web-service » c'est quoi exactement ?. Évalué à 3.
C'est surtout que les web services utilisent en principe les infrastructures du Web côté serveur, dans le sens où ils sont accessibles sur des ports connus et en utilisant les protocoles habituels (HTTP). Ceci les rend facilement accessibles depuis les réseaux d'entreprises, par exemple, en général très sécurisés et très filtrés, même depuis l'intérieur. L'avantage est que l'on utilise les mêmes couches sous-jacentes et que le XML est analysable relativement facilement. Cela évite de définir un protocole et d'accaparer un port par type de service rendu.
Ceci est associé au fait que SOAP est censé transmettre des objets, ce qui est appréciable dans le contexte actuel et lorsque les infrastructures pour gérer pleinement ce protocole sont déjà disponibles, par exemple en Java. C'est pour cela aussi que SOAP est souvent utilisé pour faire communiquer deux composants d'un même produit mais complètement distincts, par exemple un noyau en C et un GUI en Java, ceci faute de mieux parce que les protocoles d'échange d'objets pleinement aboutis, universels, libres et qui soient largement pris en charge ne sont pas légion.
Donc, c'est pratique pour mettre en place un backend public devant être exploité par des applications plutôt par l'utilisateur directement. Maintenant, ça a beaucoup d'inconvénients à l'usage également. Par exemple, c'est toujours pénible à gérer en C.