On me pose la question « citez des web services intéressants, et dites pourquoi vous les trouvez intéressants. »
J'ai beau lire la page wikipedia (en diagonale), je suis pas sûr de bien piger la question ni d'avoir une réponse subséquemment adaptée…
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network".
Donc, euh, un serveur IRC c'est un web service ?
SSH over DNS, c'est un agent dans un web service ?
Quels sont, selon vous, des web services ?
C'est un mot vague, ou pas du tout ? Z'avez des exemples ?
Je suis trop vieux-jeu pour comprendre le jargon 2.0 ?
# Les Web services s'appuie en général sur HTTP
Posté par X345 . Évalué à 10.
Je suis très très loin d'être un spécialiste des Web services et de la mouvance Web 2.0, mais je pense qu'en parlant de Web Service, on parle généralement de service pouvant être interrogés via le protocole du Web, c'est-à-dire HTTP. De manière peut-être un peu réductrice on peut voir les Web Service comme des appels de méthodes distantes tournant dans du HTTP. C'est donc censé être interopérable vu que HTTP est un protocole ouvert.
À ce titre, il me semble qu'un serveur IRC ou le DNS ne sont pas des Web services.
On désigne souvent par le terme de Web service les API offertes par certains fournisseurs de services comme :
Les API offertes par ces fournisseurs de services permettent souvent de réaliser les même opérations que celles qu'il est possible de réaliser via leur site web mais en utilisant un langage de programmation.
Il arrive même que dans ce cas le site web soit un client d'API Web qui permet de réaliser les opérations demandées.
Il existe également des fournisseurs de services qui offrent uniquement des API utilisables comme Web Service (c'est à dire qui n'ont pas de site web à côté qui offre les mêmes fonctionnalités).
D'un point de vu technique, on distingue principalement deux types de Web services (tous les deux utilisent le protocole HTTP) :
Voilà, je ne sais pas si j'ai été très clair mais j'espère au moins que ça aura eu la possibilité de te faire avancer. C'est pas très facile de trouver des informations pertinentes sur les Web Services parce qu'on tombe souvent dans le blabla commercial qui nous éloigne un peu de la réalité technique.
[^] # Re: Les Web services s'appuie en général sur HTTP
Posté par silex . Évalué à 3.
Salut,
j'ajouterais un petit exemple, celui de AMAZON EC2 avec une requête QUERY:
http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-query-RunInstances.html#ApiReference-query-RunInstances-Examples
Perso, je résume le WebService à une API distance qu'il faut interroger en sérialisant (query, soap..) ses données et en les envoyant via le protocole HTTP.
[^] # Re: Les Web services s'appuie en général sur HTTP
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Merci beaucoup pour ta longue et claire réponse qui m'est d'une grande utilité !
# Open Data
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Un bon exemple de web services est probablement tous les web services qui ont été créés pour l'initiative Open Data menée dans différents pays du monde et en particulier en France. Ainsi des applications peuvent accéder aux données publiques (horaires de bus, positionnement géographiques des services publiques, disponibilité des transports,…). La majorité des applications qui les utilisent sont des applications pour smartphone.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Open Data
Posté par Grunt . Évalué à 1.
Du coup, c'est un peu bizarre d'appeler ça "web service".
D'un côté on a une application qui n'est pas un navigateur Web, et qui est dédiée à un seul usage (afficher des horaires de bus, par exemple). De l'autre côté, un serveur publie dans un format très précis (sinon l'application ne s'y retrouverait pas) des données brutes, sans y ajouter d'informations de rendu utilisateur (pas de CSS, pas de JS pour l'interaction, juste des fichiers genre XML).
Alors certes, la couche transport utilisée est certainement HTTP, mais ce choix est, de chaque côté, totalement transparent. Ça suffit à appeler ça un "web service" ? Si une administration propose les horaires de bus via DCC (extension d'IRC qui permet d'envoyer des fichiers), que le client sur smartphone récupère ces horaires via DCC, ça marchera tout pareil, et il faudrait appeler ça un "irc service" ?
AMHA on peut parler de "web service" tant qu'on conserve un client Web côté utilisateur final, avec les spécificités du Web (le serveur fournit les données, les informations de rendu, et souvent du code à exécuter côté client).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Open Data
Posté par claudex . Évalué à 5.
C'est une raison historique, il me semble, au début, c'était plutôt utilisé dans les navigateur au travers d'Ajax.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Open Data
Posté par Obsidian . É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.
# Je suis pas expert mais d'après ce que j'ai compris :
Posté par manifesto . Évalué à 2.
On peut ajouter que les webservices type WS (utilisant SOAP) peuvent etre orchestrés par des composant que l'on appelle ESB et peuvent inclure des annuaires type UDDI.
Autre point important les WS utilisent des contrat de service en WSDL qui sont des descriptions des services et qui sont publiés, les "clients" consomment à leur tour ces services.
Les services eux mêmes sont souvent définis avec des outils qui utilisent le langage BPEL.
L'idée est de pouvoir créer des wsdl de facon graphique dans un IDE sans connaitre la programmation.
Le BPEL sera ensuite retranscrit en langage objet type Java.
Ce sont les composants principaux des architectures type SOA.
Il est a noter que contrairement au Rest(full) on peut faire des service web synchrones et asynchrones.
On peut utiliser des messages queues (JMS par exemple) pour gérer ca.
A noter la page wikipedia concise :
http://fr.wikipedia.org/wiki/Service_web
[^] # Re: Je suis pas expert mais d'après ce que j'ai compris :
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
J'adore ! :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.