Discussion :

[knebhi]

Bonjour,

J'ai développé un service web sur une plateforme peut connu du public car un peu obsolète. cependant je consomme ce service web en php avec cURL.

J'ai une question sur le choix des URI.

Mon service renvoi l'analyse d'une phrase. Cette analyse est renvoyer en differente representation(aussi bien au niveau du format qu'au niveau de la representation elle meme)
j'hesite entre ces deux niveau :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://domaine.fr/Analyse?app=XMLTei&text=le+chat+mange+la+souris

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://localhost/Analyse/XMLTei&text=le+chat+mange+la+souris

j'aimerai votre avis j'hesite entre le fait de placer le XMLTei dans l'uri et ainsi specifier qu'il s'agit d'une ressource a part entiere ou mettre le XMLTei dans un parametre app

laquelle de ces solutions est la plus ReSTful ?

merci

[wiztricks]

Salut,
Personnellement, je préfèrerais plutôt la forme:

baseURI?text=le+chat+mange+la+souris

i.e. autre chose que celles que vous avez proposé.
Ce qui suppose que baseURI de la forme:

http://localhost/Analyse/XMLTei

Mais xmltei est, je suppose, le format dans lequel vous souhaitez que soit retournée la réponse i.e. ce qui est plutôt à transférer dans l'en-tête Accept de la requête.
Du coup, je ne vois pas pourquoi baseURI ne s'écrirait pas plutôt:

http://localhost/analyses

Cordialement
- W

[knebhi]

Salut,
Personnellement, je préfèrerais plutôt la forme:

baseURI?text=le+chat+mange+la+souris

i.e. autre chose que celles que vous avez proposé.
Ce qui suppose que baseURI de la forme:

http://localhost/Analyse/XMLTei

Mais xmltei est, je suppose, le format dans lequel vous souhaitez que soit retournée la réponse i.e. ce qui est plutôt à transférer dans l'en-tête Accept de la requête.
Du coup, je ne vois pas pourquoi baseURI ne s'écrirait pas plutôt:

http://localhost/analyses

Cordialement
- W

Merci pour la réponse.
En fait je proposai la baseURI

http://localhost/Analyse/XMLTei

au lieu de l'en tête Accept car il existe d'autre sortie Xml correspondant à une analyse.
Ces differentes sortie XML correspondent à des informations parfois différentes ce qui laisse penser que XMLTei et Xml sont deux applications différentes et donc deux ressources différentes.
Dans ce contexte pensez vous que je puisse garder l'Uri de base :

http://localhost/Analyse/XMLTei

ou dois-je passser par l'en tête ?

merci

[wiztricks]

Ces differentes sortie XML correspondent à des informations parfois différentes ce qui laisse penser que XMLTei et Xml sont deux applications différentes et donc deux ressources différentes.

La question est de savoir s'il s'agit de _représentations_ différentes d'une même information retournée par BaseURI?text=le+chat+mange+la+souris, sachant que représentation est à prendre au sens retourne des "vues" différentes d'une même ressource.

Dans ce contexte pensez vous que je puisse garder l'Uri de base:
http://localhost/Analyse/XMLTei

Vous pouvez toujours la garder, surtout s'il y a des clients qui s'en servent.
Mais vu qu'elle est associée à un format particulier, c'est pas trop "REST".
- W

[knebhi]

La question est de savoir s'il s'agit de _représentations_ différentes d'une même information retournée par BaseURI?text=le+chat+mange+la+souris, sachant que représentation est à prendre au sens retourne des "vues" différentes d'une même ressource.



Vous pouvez toujours la garder, surtout s'il y a des clients qui s'en servent.
Mais vu qu'elle est associée à un format particulier, c'est pas trop "REST".
- W

oui dans ce cas on peut dire qu'il s'agit d'une representation differente d'une meme ressource qui est un analyseur.
si je comprends bien il faut que je repense mon architecture pour etre "ReSTful".

[knebhi]

je viens de voir que mon service ne gérait que la version 1.0 du protocole HTTP.
Par consequent pas de Accept mais Content-type.

ça me semble pas etre la mais chose non?

[wiztricks]

je viens de voir que mon service ne gérait que la version 1.0 du protocole HTTP.
Par consequent pas de Accept mais Content-type.

ça me semble pas etre la mais chose non?

Content-* s'appliquent au contenu (réponse à un GET ou associé à un PUT/POST). Ceci dit, Accept n'est pas insupportable en 1.0, voir w3c
Testez voir ce que fait votre serveur Web dans ce cas et comment vous pouvez en récupérer la "valeur" plus bas.
- W

[knebhi]

Content-* s'appliquent au contenu (réponse à un GET ou associé à un PUT/POST). Ceci dit, Accept n'est pas insupportable en 1.0, voir w3c
Testez voir ce que fait votre serveur Web dans ce cas et comment vous pouvez en récupérer la "valeur" plus bas.
- W

voila ce que me renvoit mon serveur pour une requete GET :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Date: Wed, 02 Mar 2011 16:32:15 GMT
Content-Length: 698
Last-Modified: Wed, 02 Mar 2011 16:32:15 GMT
Content-Type: text/xml; charset=utf-8
Cache-Control: no-cache
Expires: Wed, 02 Mar 2011 16:32:15 GMT

Comme vous le voyez j'ai bien specifier dans mon service que le contenu etait du xml.
Par contre comment mettre en place le Accept?

J'utilise Client REST simple sur Chrome.
Dans l'entete j'essai d'utiliser le Accept en changeant sa valeur mais il me renvoi toujours le xml et pas d'erreur...

[wiztricks]

Comme vous le voyez j'ai bien specifier dans mon service que le contenu etait du xml. Par contre comment mettre en place le Accept?

Tout dépend comment est construit votre serveur.
Lorsque la rêquete HTTP arrive, il faut savoir quoi en faire en fonction de la baseURI et éventuellement de la méthode.
La requête est passée à une action/application/contrôleur qui doit construire la réponse. Ici, récupérer "l'état interne de la resource" et la retourner dans le body de la réponse dans le format demandé.

Reste à savoir si "action/application/contrôleur":
- récupère le header,
- sait en faire quelque chose pour formatter la réponse

Quand vous faites quelque chose qui veut ressembler à du ReST, vous vous contraignez à utiliser des URI, les méthodes HTTP (GET, POST,...) et les headers pour traiter format, charset,... des représentations échangées.
En gros, cela définit une API 'simple' à réaliser mais à réaliser quand même.
- W

[knebhi]

Tout dépend comment est construit votre serveur.
Lorsque la rêquete HTTP arrive, il faut savoir quoi en faire en fonction de la baseURI et éventuellement de la méthode.
La requête est passée à une action/application/contrôleur qui doit construire la réponse. Ici, récupérer "l'état interne de la resource" et la retourner dans le body de la réponse dans le format demandé.

Reste à savoir si "action/application/contrôleur":
- récupère le header,
- sait en faire quelque chose pour formatter la réponse

Quand vous faites quelque chose qui veut ressembler à du ReST, vous vous contraignez à utiliser des URI, les méthodes HTTP (GET, POST,...) et les headers pour traiter format, charset,... des représentations échangées.
En gros, cela définit une API 'simple' à réaliser mais à réaliser quand même.
- W

Après avoir lu des lignes de codes. j'ai pu trouver une solution.
j'utilise bien le HTTP 1.1 et j'ai bien trouvé la solution pour utiliser Accept dans l'entête.
J'ai donc paramétrer pour avoir la réponse souhaitée selon la valeur de Accept dans l'entête.
Ensuite je renvoi ma representation de la ressource decrite par l'uri :
/Analyse

J'ai donc enlever le parametre app comme conseiller.

reste a voir ce que je peux encore faire pour avoir une architecture la plus ReST possible

[wiztricks]