REST + AJAX, quel couple ! (3/3)

Partie 1
Partie 2

5. Templates

Pas vraiment d’idées à ce sujet. On peut peut  être utiliser un language type Perl/Python/Ruby pour générer les pages statiques non dynamiquement (générées une fois pour toute) à partir de templates.

Une autre solution consiste à n’utiliser qu’un fichier html pour tout le site, mais je crains que le développement ne devienne un peu fastidieux et qu’on perde tout l’aspect structuré de l’HTML.

6. Indexation des moteurs de recherche

C’est là où le bas blesse. En fait, nos pages sans javascript ne sont pas consultables. Donc là je vais proposer de croiser les doigts bien forts et d’esprérer qu’une nouvelle balise qui tue fasse son apparaition. Par exemple :

<content html="displayArtiste(mr-tac)"  data="/playlist/artistes/mr-tac/rdf/" />

Pour le navigateur, les données sont affichées avec displayArtiste()  et pour le  moteur/analyseur syntaxique, tout est à disponible à l’URI contenue dans data. Cela ferait disparaître, l’aspect opaque du javascript tout en conservant ses qualité ergonomiques.

7. Défauts

  • Un tel site demande un coût important en réalisation. Décrire chaque donnée précisément, assurer un accès propre et dans plusieurs formats n’est pas immédiat. Toutefois on pourrait se limiter à certaines formats et ne décrire avec précision que les données sensibles. De plus, un framework adapté permettrait de ne coder qu’une fois les données et de générer le format désiré automatiquement.
  • Le développement en javascript n’est pas aussi trivial que le développement pur HTML.
  • L’interfaçage avec les navigateurs pour aveugle n’est pas aisé.
  • Enfin, les vieilles machines supportent mal le javascript, voir ne le supporte pas du tout. Ce qui peut limiter l’accès au site web ainsi réalisé.

Conclusion

Au final rien de bien nouveau à part que l’on joue aux extrêmistes du REST tout en profitant de la souplesse ergonpmique de l’AJAX. Alors, pourquoi en parler ? Tout simplement car je n’ai jamais vu un seul site fonctionner ainsi. Les frameworks en vogue sont proches de ce type d’architecture, mais poussent à servir des pages webs dynamiquement générés par du python, ruby ou PHP (ce qui reste lourd pour le serveur).

GWT avec un fonctionnement un peu différent propose de générer des applications 100% javascript. Mais là encore on tombe sur une véritable boite noîre qui produit du code HTML souvent difficile à mettre en forme et pas toujours respectueux des standards.

Pourtant, la plupart des outils sont là pour développer une telle architecture. L’établissement de certains standards sur le format des URI permettrait le développement de frameworks optimisés pour ce type de site web. De plus, l’engouement des interconnexions entre les sites webs dotés d’une telle organisation pousserait les autres à s’y mettre. Enfin, REST et Ajax sont très à la mode, il ne manque donc pas grand chose pour que leur union se démocratise.

Advertisements

REST + AJAX, quel couple ! (2/3)

Partie 1
Partie 3

2. Accès aux données

REST permet d’effectuer les opérations classiques CRUD (Create, Retrieve, Update, Delete) sur chacune des ressources issues de la base de données. On va donc pouvoir mapper toutes les opérations classiques du SQL avec des méthodes de reqête HTTP sur des URI bien définies. Par exemple l’URI du domaine dolebrai.net renvoie les informations sur l’artiste Mr Tac lorsqu’on lui transmet une requête de rappatriement (méthode GET) :

dolebrai.net/playlist/artistes/mr-tac/

Il m’est aussi possible de supprimer l’artiste Mr Tac en envoyant une requête de type DELETE ou de le mettre à jour avec une requête UPDATE.

Enfin, j’aurais très bien pu envoyer une requête POST accompagnée des données nécessaires à l’URI suivante pour créer un nouvel artiste :

dolebrai.net/playlist/artistes/

Pour en savoir plus, je vous renvoie aux nombreuses documentations à ce sujet. Point de vue technologies, nombre de possibilités vous sont offertes : MERB, django-rest, Restlet…

Pour aller plus loin et donner un accès complet aux données du site, on peut également renvoyer les données sous plusieurs formats :

dolebrai.net/playlist/artistes/mr-tac/xml/
=> pour une information bien structurée
dolebrai.net/playlist/artistes/mr-tac/html/
=> pour l'afficher sans traitement
dolebrai.net/playlist/artistes/mr-tac/json/
 => pour une manipulation facile via javascript
dolebrai.net/playlist/artistes/mr-tac/rdf/
 => pour que les moteurs de recherche saisissent le sens des données

La communication entre sites web en ressort facilitée, n’importequel site voulant récupérer les informations sur Mr Tac contenue sur dolebraï.net au format de son choix pourra ainsi le faire.

3. Accès fichier statique

Les fichiers statiques sont aussi des données. Il faut donc aussi qu’ils soient caractérisés par une URI pertinente et qui ne se termine pas par une extension du type .mp3, .html, .xml… On aura par exemple :

dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/tracks/01-my-first-song/file/mp3/
=> fichier 01_myfirstsong.mp3
dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/tracks/01-my-first-song/file/ogg/
=> fichier 01_myfirstsong.ogg
dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/cover/front/
=> fichier myfirstalbum_front.png
dolebrai.net/playlist/artists/mr-tac/
=> artist.html

NB : Le problème d’une telle redirection est qu’on perd le côté instantané du rappatriement d’un fichier statique.

4. Navigation

Le site web se résume à une simple série de fichiers html. D’ailleurs, un seul suffirait. Pour raison de commodité et pour éviter une effet d’opacité comme dans GWT, on préférera plusieurs fichiers HTML décrivant les sections du site. Disons que pour chacun des fichiers templates qu’on aurait créé avec un framework classique , il faudrait un fichier HTML. Ainsi notre redirection serait un peu plus complexe :

dolebrai.net/playlist/artists/mr-tac/
=> artist.html?artist=mr-tac

ou plutôt :

dolebrai.net/playlist/artists/mr-tac/
=> playlist.html?type=artiste&artist=mr-tac

Le layout serait codé en HTML statique et les données seraient fonction des paramètres. Un clic sur un artiste n’entrainerait pas un rechargement complet de la page mais seulement la partie données dynamiques.

Conclusion de la deuxième partie

En résumé, votre interface REST devient le centre de l’application. Que ce soit un intervenant externe ou vos pages AJAX, tout le monde emprunte ce chemin pour accéder aux ressources de votre site web, et ce quel que soit leur type.

Schéma d'une architecture de site web centralisé sur une interface web