Pour rebondir sur les propos de Christian qui essaye de combiner REST et RDF, je voudrais discuter de l'architecture « idéale » à laquelle je suis arrivé. C'est une problématique à laquelle je suis confronté aussi lors de ma réflexion pour la killer app sémantique et qui fait partie des trois points bloquants actuels avec l'ergonomie et la confidentialité des données.

Il y a désormais deux livres qui ont vraiment influé sur ma façon de concevoir une application. Le premier est Getting Real dont je n'ai jamais fait la critique mais qui est vraiment à lire et à relire (et à offrir à vos collègues de travail s'ils ont encore suffisamment de curiosité pour évoluer). Le second est RESTful Web Services dont j'ai déjà parlé dans mon billet sur l'architecture orientée ressource et que j'ai maintenant terminé.

Le plus gros défaut de REST, c'est sûrement de se limiter à la comparaison des 4 verbes HTTP (GET, POST, PUT et DELETE) aux 4 actions possibles sur des données issues de bases de données (Retrieve, Create, Update et Delete soit CRUD mais j'ai laissé dans l'ordre de la comparaison). Et le pire, c'est que je suis tombé dans ce « piège » dans mon précédent billet sur REST (même si c'était une traduction), il est temps de parler plus en détail des possibilités offertes par une telle architecture.

Depuis quelques mois, j'apprends j'essaye d'apprendre REST et j'ai lu de nombreuses pages sans pour autant trouver d'explication simple, à la portée de tous. Du coup quand j'essaye d'expliquer les mécanismes et les avantages professionnellement, c'est pas toujours convaincant... et je voulais justement écrire un petit billet pour mettre tout ça au clair. Et puis je suis récemment tombé sur une série d'explications par Softies on Rails se basant sur des exemples concrets. En voici la traduction chronologique.