Discussion:Service web

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Critique de 2007 concernant le Rest dans l'article Service web[modifier le code]

Je trouve maladroit de parler de REST en premier lieu et de le mettre ainsi en avant. moi aussi j'aime bien REST ;-) , mais force est de constater que les WS-* arrivent avant historiquement, et sont plus usité de fait. Par abus de langage, Webservice = XML/SOAP/HTTP, même si c'est réducteur, c'est une réalité. Il faut savoir dans cette encyclopédie donnée une vision objective de ce thème.

Cet article est largement biaisé en faveur de REST, contrairement à la version anglaise qui est bien plus neutre et descriptive. On croirait entendre discuter mes collègues qui reviennent des TechDays Microsoft ! Je n'ai pas trouvé comment mettre un avis sur un sujet existant: J'appuie cet énoncé surtout que REST a été mis en œuvre non pour SOA mais plutôt pour WOA. L'approche REST n'a pas la solidité requise pour répondre a plusieurs besoins pour des systèmes dont l'intégrité doit être garantie.--24.201.251.253 (discuter) 19 août 2015 à 12:14 (CEST)[répondre]

Avantages - Protocole HTTP - pare-feux[modifier le code]

J'ai deux remarques à formuler quant à la phrase "Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux pare-feux sans nécessiter des changements sur les règles de filtrage." 1) Bien que le protocole HTTP utilise un port part défaut (80 ou 443 pour la version SSL), ce port n'est pas toujours utilisé pour les services WEB (dans mon expérience personnelle, c'est même rarement le cas). Il est donc souvent nécessaire de créer des règles particulières pour les services WEB. 2) Ne pas avoir à se poser de question par rapport à la sécurité me semble être en soi un problème de sécurité : il serait bien plus sûr d'avoir à définir des règles spécifiques pour les services WEB sur les pare-feux que d'utiliser un port fourre-tout où l'on trouve l'intranet, l'extranet, les services WEB, mais aussi parfois des VPN, du SSH, etc. Si l'utilisation du port HTTP (80) est un fait (ce qui contredirait ma première remarque), je ne placerait pas ce fait dans les avantages.

J'ai corrigé l'article pour tenir compte des remarques du contributeur précédent.
Les services WS sont faciles à installer même sur un site utilisant des pare-feu, mais si on veut mettre en place une sécurité spécifique pour chacun de ces services, on ne peut plus utiliser les paramétrages de base des pare-feu.
Exemple : l'adresse IP du serveur est utilisé pour deux WSDL, l'un accessible pour l'intERnet en entier, l'autre accessible uniquement pour l'intRAnet). Discussion utilisateur:Romanc19s (discuter) 10 novembre 2013 à 11:55 (CET)[répondre]

Evolution[modifier le code]

Je ne sais comment faire évoluer cet article. Je ne vois pas ce que viennent y faire les descriptions de Rest et des WS*, qui font doublon avec les articles qui leur sont consacrés, il me semble. J'ai corrigé, j'espère, un ou deux trucs ici et là, mais ça reste fouillis. Il me semble qu'il serait mieux d'y placer des comparaisons entre les différentes technologies, plutôt que la description de ces technologies ? Touam (d) 10 octobre 2009 à 16:48 (CEST).[répondre]

Cette remarque de 2009 me semble toujours valable. Il y a doublon avec Representational State Transfer, et peut-être avec certains articles concernant le WS (WSDL ?). Il faudrait faire un ménage radical dans l'article service web, en reportant éventuellement ce qui a été supprimé dans d'autres articles de wikipedia. Discussion utilisateur:Romanc19s (discuter) 10 novembre 2013 à 12:11 (CET)[répondre]

WebService: Programme?[modifier le code]

Le webservice est ce que vous voulez, mais une chose est certaine, c'est que ce n'est pas un programme... c'est une bibliothèque contient des classes est méthodes

Pas très clair[modifier le code]

Bonjour à toutes et toutes, et d'abord, merci pour votre travail. Personnellement, je suis informaticien, mais je n'y comprends pas grand chose aux WebServices. Je ne sais pas trop ce que je ne comprends pas, mais je ne comprends pas. Et cet article, franchement, ne me fait pas mieux comprendre le sujet. N'y aurait-il pas possibilité de le rendre encore plus pédagogique ? Ou alors d'indiquer les prérequis de connaissances nécessaires pour comprendre ce sujet ? 194.250.5.173 (discuter) 20 juin 2016 à 10:50 (CEST)[répondre]

J'ai ajouté un lien vers le Wiktionnaire (à la fin) qui la résume en une phrase. JackPotte ($) 20 juin 2016 à 22:26 (CEST)[répondre]

Modèle OSI[modifier le code]

C'est noté "Actuellement, le protocole de transport est essentiellement HTTP." HTTP n'est pas plutôt sur la couche application et non transport dans le modèle OSI ? NumOpen (discuter) 13 mars 2022 à 18:11 (CET)[répondre]

Oui tout à fait, c'est plutôt TCP via HTTP : je corrige. JackPotte ($) 13 mars 2022 à 21:41 (CET)[répondre]