18 Juil 2007, 10:17
Défaut:
by

2 comments

Activation de compte en mode REST

Voici la traduction d’une partie d’une note de Seth Ladd. Il reprend les idées clés que j’évoquais dans ma note sur RESTful Web Services en donnant un exemple concret de mise en oeuvre des principes REST.

[…] Dans le monde des applications web REST, tout ce que vous voyez sont des objets., ou des noms. Les verbes du système sont limités aux méthodes HTTP telles que GET, PUT, POST, and DELETE. REST vous invite à interagir avec le monde des choses avec seulement 4 méthodes. Cela vous oblige à vous demander : « Comment puis-je convertir une Action en une Chose ? »

[Pour une authentification en mode REST], l’action est Login, mais cette action est encapsulée dans un objet Session. Quand vous vous authentifiez (login), vous créez une nouvelle SESSION. Quand vous quittez (logout), vous effacez cette Session (ici, la Session est un concept différent d’une session web). [En mode REST on définit] les actions login et logout par CREATE Session et DELETE Session.

On peut appliquer ce concept à l’action de compte, ce que j’ai eu à faire récemment pour une de nos applications. Nos politiques stipulent qu’un compte ne peut accéder au système qu’à partir du moment où un administrateur l’a activé.
Dans l’ancien monde pré-REST, nous aurions modélisé ceci avec une action nommée activate, qui aurait activée un bit sur l’instance du compte. Cà aurait très bien marché. Mais ce n’est pas RESTful pour autant, car il aurait fallu un nouveau verbe dans le système. ( activate).

Sachant que REST c’est d’abord des noms, nous avons substantivé le concept d’activation dans une classe nommée Activation. Nous disons qu’un Compte a une Activation et, si cette relation d’activation existe, le Compte est activé. S’il n’y a pas de d’instance d’activation pour un Compte, alors le Compte est désactivé.
Un administrateur va CREATE (créer) une instance d’activation afin d’activer un Compte. L’admininstrateur peut, ultérieurement, DELETE cette instance d’activation si l’on veut désactiver le Compte.

Un autre bénéfice dans la création d’une classe Activation est que l’on peut ajouter des propriétés telles que « quand le Compte a été activé et par qui? ».

En résumé, j’aime travailler en REST car cela m’oblige à penser avec des noms, qui sont des classes. Je trouve que c’est plus facile de représenter le monde avec des noms qu’avec des verbes. De plus, le problème des verbes est que l’on ne peut rien dire sur eux, aussi perd-t-on la possibilité de leur ajouter des métadonnées aux événements du système.

13 Août 2007, 5:41
by Fabrice Le Coz

reply

L’authentification d’utilisateur par un service REST ne doit en aucun cas être géré par des sessions, un service REST est « Stateless », l’identification d’un uilisateur doit donc se faire via le protocole http qui d’ailleurs propose une solution d’authentification et de rejet via l’erreur 401.

[Reply]

Seth précise que le terme de « session » n’est pas à comprendre au sens de « session web ». Merci d’avoir souligné ce point dans ton commentaire. 🙂

[Reply]

 

Répondre à Fabrice Le Coz Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.