Discussion :

[REMACC1]

Bonjour,

j'ai défini un service web qui retourne un objet de type User. Je n'ai pas de problème pour utiliser ce User dans mes applications clientes en appelant le service web concerné. Je voudrais désormais dans une application cliente ne pas utiliser l'objet User mais récupèrer celui-ci sous forme de fluxXML. Au lieu d'utiliser l'objet, je voudrais récupèrer le fluxXML renvoyer par le service web afin de pouvoir parser celui-ci et de l'utiliser à ma convenance.
Merci par avance.

[bacelar]

Faites une requête HTTP (http://msdn.microsoft.com/fr-fr/libr...st(VS.80).aspx) et n'utilisez pas les classes proxys générés pas wsdl.exe.

Franchement, je ne vois pas l'intérêt de passer par des WebServices si c'est pour parser du XML. HTTP le fait très bien.

[tomlev]

Franchement, je ne vois pas l'intérêt de passer par des WebServices si c'est pour parser du XML. HTTP le fait très bien.

Sauf si c'est pas une appli .NET
Quoi qu'à mon avis la plupart des plateformes proposent la génération de proxies pour les WS...

[keevkilla]

Bonjour à tous,

Je me permets de relancer la discussion car ma problématique est très proche de celle décrite dans le premier post.

De fait il faut effectivement que je capture le contenu d'une requête HTTP, or dans mon cas, il ne s'agit pas d'appeler une URL et de capturer la réponse, mais plutôt mettre à disposition une méthode via une URL (ça ressemble à du WebService) et que lorsque cette URL est appelé, la méthode capte le flux XML contenu dans le "content" de la requête HTTP appelante.
Je sais ça paraît tordu mais j'ai pas le choix de la solution.

Si vous avez besoin de précisions, ou même que je rééxplique éventuellement dans d'autres termes, je me ferai un plaisir de le faire.
Je vais aussi faire un schéma que je mettrai à dispo sur une URL.

Merci d'avance de vos réponses,
Keev

[keevkilla]

Ma problématique, comme j'ai tenté de l'expliquer dans mon précédent post, est de réaliser en C# ASP.NET, les étapes 1 - 2 - 3 du schéma en pièce-jointe.

[bacelar]

Si vous n'avez pas besoin de toute l'infrastructure d'encapsulation et d'interopérabilité des WebService, utilisez de préférence le protocole REST, bien moins contraignant.
Des solutions .NET existent pour utiliser efficacement REST.

[keevkilla]

Je n'ai effectivement pas besoin de l'encapsulation et de tous les bienfaits des WebServices de type WSDL/SOAP, mais ma question, et plutôt technique (pas vraiment sur le choix de la méthode). En gros je me pose les questions suivantes, pour faire un webservice REST :
- quels sont les fichiers à mettre en place ?
- quelle est la configuration qu'il me faut implémenter sur mon IIS6.0 ?
- et enfin quelles sont les méthodes qui permettent (en C#) de récupérer le "content" d'une requête HTTP ?

Je suis preneur de toute bonne référence vers un Tuto.

Je bosse sous .NET Framework 3.5 et IIS 6.0.

Oui, je sais, je ne sais rien, mais j'ai pas le choix... donc merci pour votre aiiiiide.

Cordialement

[bacelar]

Avec les technologies offertes par M$, REST est plus un canal de communication utilisé pour implémenter des fonctionnalités de haut niveau que l'approche bas niveau de REST.

Donc, utilisez-vous des technologies type Entity Framework ou autres qui utilise REST en sous-main, et là il vaudrait mieux utiliser pleinement ces technologies que de réinventer la roue.

Un exemple d'utilisation de REST pour une application utilisant ASP.NET MVC :
http://msdn.microsoft.com/fr-fr/magazine/dd943053.aspx

ASP.NET a donc tendance à encapsuler REST pour simplifier l'implémentation des couches supérieures des applications.

- quels sont les fichiers à mettre en place ?
- quelle est la configuration qu'il me faut implémenter sur mon IIS6.0 ?

Cela dépend du type d'encapsulation.

- et enfin quelles sont les méthodes qui permettent (en C#) de récupérer le "content" d'une requête HTTP ?

Bin, comme depuis une décennie : la classe HttpRequest(http://msdn.microsoft.com/fr-fr/libr...tprequest.aspx) dans le membre Request d'une page.