Discussion :

[topolino]

Bonjour,

je suis en train de regarder les difference entre SOAP et REST. Pour l'instant mes tests se portés sur SOAP, d'ailleurs qd j utilisais mais services en .net j avais un proxy generé automatiquement et c'etait le bonheur, par contre des difficultés lorsque je voulais consommer mes servives avec Javascript ou les asp classic.

Je me suis donc interessé à REST, ca a l'air seduisant pour etre plus generaliste il me semble (je veux etre consommé par php, java, javascript, asp, asp.net, ruby......). Par contre si je veux l utiliser en .net, est ce qu un proxy sera generé ou devrais je utilisé les webhttprequest ?

quels sont vos conseils ?

Merci

[Invité]

Je me suis donc interessé à REST, ca a l'air seduisant pour etre plus generaliste

je dirais plutôt simpliste.

Par contre si je veux l utiliser en .net, est ce qu un proxy sera generé ou devrais je utilisé les webhttprequest ?
quels sont vos conseils ?

Supposons que tu ais un service WCF MonService que tu veux exposer au monde extérieur et parmi ce monde nous avons deux applications clientes qui veulent communiquer avec. Supposons que nous avons les applications suivantes :

• La première application AppliJavaScript veut communiquer au format JSON avec MonService
• La deuxième application AppliDotNet (une application basée sur le Framework .net) veut communiquer avec le même service en utilisant SOAP

Les deux applications citées précédemment communique de façon différente avec MonService. Pour que cela soit possible il faut que MonService propose deux points d'entrée différents :

• un point d'entrée pour les communications REST/JSON qui sera utilisé par AppliJavaScript.
• un point d'entrée pour les communications pures SOAP et qui sera utilisé par AppliDotNet. Et pour la génération du proxy par VS cela ne posera pas de problème. (Bien sûr il faut que les métadonnées soient publiées).

Tout cela pour dire qu'il faut juste jouer aux niveaux des points d'entrée.
Si j'ai N applications clientes qui veulent communiquer de N manières différentes avec mon service, je mettrai en place N points d'entrée différents et chaque application cliente utilisera le point d'entrée qui lui convient.

[Nathanael Marchand]

je dirais plutôt simpliste.


Supposons que tu ais un service WCF MonService que tu veux exposer au monde extérieur et parmi ce monde nous avons deux applications clientes qui veulent communiquer avec. Supposons que nous avons les applications suivantes :

• La première application AppliJavaScript veut communiquer au format JSON avec MonService
• La deuxième application AppliDotNet (une application basée sur le Framework .net) veut communiquer avec le même service en utilisant SOAP

Les deux applications citées précédemment communique de façon différente avec MonService. Pour que cela soit possible il faut que MonService propose deux points d'entrée différents :

• un point d'entrée pour les communications REST/JSON qui sera utilisé par AppliJavaScript.
• un point d'entrée pour les communications pures SOAP et qui sera utilisé par AppliDotNet. Et pour la génération du proxy par VS cela ne posera pas de problème. (Bien sûr il faut que les métadonnées soient publiées).

Tout cela pour dire qu'il faut juste jouer aux niveaux des points d'entrée.
Si j'ai N applications clientes qui veulent communiquer de N manières différentes avec mon service, je mettrai en place N points d'entrée différents et chaque application cliente utilisera le point d'entrée qui lui convient.

Exactement! La grande force de WCF c'est vraiment d'abstraire se genre de préoccupation. Dans le même ordre d'idée, j'expose mes services soit avec une authentification windows soit login/pwd. C'est deux points d'entrée (endpoints) du même service.

[topolino]

Vraiment merci pour ces explications. De ce que j ai pu voir c'est aussi au niveau des attributs que cela differt.

Je vais faire qq tests alors.

Merci