Hmmm
Une des grosses difficultés pour REST est de penser ReST.
Ce qui suppose définir des ressources i.e. des "noms" et se limiter à des opérations HTTP POST, GET, ...
Ce sont les seules méthodes que vous pouvez appliquer aux ressources.
La ressource est une URI et ce que fait le serveur avec les requêtes qu'il reçoit sur ces URI est "ouvert" mais pas n'importe quoi non plus!
Si vous pensez fonctions arguments vous êtes dans du XML-RPC/SOAP... vous pensez "méthodes"/verbe et non ressource/noms.
C'est un "paradigm shift" pas si facile à faire lorsque vous venez du monde objet. Un objet c'est un nom et des comportements (behaviors/methodes).
Une ressource ReST c'est une URI et quelques méthodes HTTP.
2 Ressources :
Eleves - Contenant des infos diverses sur l'eleve
Devoirs - Trié par classe et type, chaque devoir et lié a un eleve.
Vous pensez "tables" d'un modèle relationnel.
En jargon ReST, nous dirions plutôt: /rest_ressources/eleves est l'URI de la ressource qui permet d'accéder à la collection de ressources eleves.
"chaque devoir est lié a un eleve" se traduit par une "descente" dans la ressource élève:
/rest_ressources/eleves/[ident]/devoirs
qui donne accès à la liste des devoirs de l'élève [ident], et:
/rest_ressources/eleves/[ident]/devoirs/[ident_devoir]
pour accéder à un devoir particulier.
Classes (/rest_ressources/classes): elle défini une collection d'élèves
Devoirs (/rest_ressources/devoirs): pour la collection des devoirs indépendamment des élèves...
La fonction GetNbDevoir prend 2 arguments : L'ID d'eleve et l'etat du devoir (Traiter ou en attente de traitement ou les deux)
Quel est le nombre de devoir que l'élève à fait ou a à faire?
C'est quelque chose associé à élève et qui pourrait très bien figurer dans les attributs de la représentation d'état retournée par GET sur l'URI /rest_ressources/eleves/[ident]
Vous pourriez aussi vouloir récupérer des "listes de" et dans ce cas passer par l'URI /rest_ressources/eleves/[ident]/devoirs
Pour faire un query en fonction de l'état "fait", "à faire", vous pourriez l'exprimer:
/rest_ressources/eleves/[ident]/devoirs?etat=fait
=> ca va retourner une liste de... URI vers des devoirs faits par l'élève ident
SetDevoir prends 1 args: L'Id du devoir pour faire passe l'etat de attente de traitement a traie.
Puisqu'on change l'état, c'est au moins un POST(*), l'URI de la ressource pourrait être:
/rest_ressources/eleves/[ident]/devoirs/[ident_devoir]
Dans le corps du message, vous pouvez indiquer ce que vous voulez.
(*) ou PUT, ou EDIT mais on va pas chipotter
Pour l'instant, nous n'avons travaillé que sur l'API présentée aux applications pour leur permettre d'échanger les représentations d'état. Nous n'avons rien dit sur le schéma de la BDD (derrière le serveur ReST). Comme dans le cas de services SOA, ce qui se passe derrière la scène doit rester "opaque".
Les autres contraintes ReST pas facile à adresser lorsqu'on vient d'un monde SOA sont idempotence et stateless. Mais, çà suffit pour aujourd'hui
- W
Partager