Architecture web moderne, le nerf de la guerre : les données (1)
Bon, suite de mes visions architecturales pacorabiennes. Cette fois cela va être plus concret. Le sujet du jours est : les données.
Ma position est assez simple : la couche d'accès aux données (DAL) doit être directement exposée sur le web. (Ce qui ne signifie qu'elle doit être en lecture/écriture ni même en lecture pour tout le monde ; l'authentification étant gérée par ce que fournissent http et https en standard, pas de sessions.)
Chaque ressource correspond à un objet, une entité (biffez la mention inutile). Les relations sont remplacées par des hyperliens.
Pour les cas simples, une table/une vue peut directement être mappée sous le chemin :
Le minimum nécessaire de types de représentations est : html, xml et js pour permettre, respectivement, de :
Bon, bien sûr cela ne couvre que la lecture (et encore je n'ai pas insité sur le fait que les headers ETag et Last-Modified doivent être utilisés). Pour l'écriture distinguons les 3 opérations de modification : création, modification et suppression. Mais je ne vais pas mapper ces opérations sur les méthodes http PUT, POST et DELETE. Pas complètement. Je n'aime pas la sémantique du PUT qui consiste à laisser l'initiative du nommage au client ce qui est, pour moi, une abération.
Donc pas de PUT mais un POST de la ressource sur une url "factory" (typiquement
Reste le DELETE qui est parfait mais ne fait pas partie de Lo-Rest, il faut donc penser à proposer au client une alternative Lo-Rest au DELETE de la ressource. C'est facile, il est juste nécessaire d'y penser).
NB : En Ajax il est possible d'être Hi-Rest. PUT et DELETE sont disponibles.
Pour les simples modifications, il suffit de poster une représentation de la ressource modifiée à sa propre adresse.
Facile n'est-il pas ?
Pour les prochains billets il me reste à couvrir : comment imposer les intégrités métiers (sous-titre : "Sur le web personne ne sait que vous êtes une procédure stockée.") et comment gérer les transactions.
Ensuite, c'en sera fini de la couche d'accès aux données et je traiterai de la couche logique et de la couche présentation.
Ma position est assez simple : la couche d'accès aux données (DAL) doit être directement exposée sur le web. (Ce qui ne signifie qu'elle doit être en lecture/écriture ni même en lecture pour tout le monde ; l'authentification étant gérée par ce que fournissent http et https en standard, pas de sessions.)
Chaque ressource correspond à un objet, une entité (biffez la mention inutile). Les relations sont remplacées par des hyperliens.
Pour les cas simples, une table/une vue peut directement être mappée sous le chemin :
/nom-de-la-table/valeur-de-la-clé-primaire et renvoyer (après négociation du type de la représentation, ici du javascript) : {
id: 'abcdef',
champ1: 3.14,
champ2: Date(1978, 10, 11),
relation1: Ref('table2/189'),
relation2: [Ref('table1/234'), Ref('table1/567')]
}Le minimum nécessaire de types de représentations est : html, xml et js pour permettre, respectivement, de :
- naviguer à travers les données depuis un simple navigateur,
- maximiser l'interopérabilité (à part le locomotive basic tous les environnements de dev sont à présents équipés de librairies correctes pour traiter ce bon vieil xml)
- accélérer le développement d'applis webs modernes.
Bon, bien sûr cela ne couvre que la lecture (et encore je n'ai pas insité sur le fait que les headers ETag et Last-Modified doivent être utilisés). Pour l'écriture distinguons les 3 opérations de modification : création, modification et suppression. Mais je ne vais pas mapper ces opérations sur les méthodes http PUT, POST et DELETE. Pas complètement. Je n'aime pas la sémantique du PUT qui consiste à laisser l'initiative du nommage au client ce qui est, pour moi, une abération.
Donc pas de PUT mais un POST de la ressource sur une url "factory" (typiquement
/nom-de-la-table) qui redirigera (header "Location:") sur l'adresse de la ressource nouvellement créée après avoir répondu 201 Created.Reste le DELETE qui est parfait mais ne fait pas partie de Lo-Rest, il faut donc penser à proposer au client une alternative Lo-Rest au DELETE de la ressource. C'est facile, il est juste nécessaire d'y penser).
NB : En Ajax il est possible d'être Hi-Rest. PUT et DELETE sont disponibles.
Pour les simples modifications, il suffit de poster une représentation de la ressource modifiée à sa propre adresse.
Facile n'est-il pas ?
Pour les prochains billets il me reste à couvrir : comment imposer les intégrités métiers (sous-titre : "Sur le web personne ne sait que vous êtes une procédure stockée.") et comment gérer les transactions.
Ensuite, c'en sera fini de la couche d'accès aux données et je traiterai de la couche logique et de la couche présentation.