Vers un Drupal 8 RESTful pour un Web non-HTML

L'année 2011 semble avoir marqué un tournant pour Drupal et sa communauté de développeurs. En effet, ce que j'appelle le "Drupal mothership", ou vaisseau mère de Drupal – l'entreprise Acquia et son leader Dries Buytaert –, et les quelques contributeurs vraiment (hyper)actifs  (sans oublier les "14,741 Developers" et parfois contributeurs fièrement affichés sur le site officiel !) nous montrent que Drupal n'a pas fini de nous réserver des surprises.

La  reconnaissance mondiale de Drupal et son utilisation massive au cours des dernières années autant pour de "petits" sites que pour des sites à fort trafic entraînent des bouleversements organisationnels initiés par le fondateur Dries Buytaert. Parallèlement aux élections de la "Drupal Association" qui a pour but de gérer les évènements et la promotion de l'outil, des actions sont menées et regroupées par pôles ou "major core initiatives" afin de répondre au mieux aux besoins du Web de demain avec la version 8 de Drupal.

C’est sur son blog, dans l'article intitulé "Drupal 2011 retrospective and 2012 predictions" datant du 5 janvier dernier, que Dries Buytaert nomme officiellement les responsables de chaque initiative:

  • Configuration Management : Greg Dunlap
  • Web Services : Larry Garfield
  • Multilingual : Gábor Hojtsy
  • HTML5 : Jacine Luisi
  • Design : Jeff Burnz
  • Mobile : John Albin

A noter qu'un petit descriptif de chaque initiative est disponible sur cette page, avec le profil du leader et son annonce officielle : http://drupal.org/community-initiatives/drupal-core

Je vais détailler dans la suite de cet article l'initiative consacrée aux Web Services, et sur les conséquences en matière de développement que cela entraîne.

--

Sur le groupe officiel de son initiative intitulée "Web Services and Context", on peut lire en introduction : "The Web Services and Context Core Initiative (WSCCI) aims to transform Drupal from a first-class CMS to a first-class REST server with a first-class CMS on top of it. […]”

Le but de la chose est donc de faire du Drupal que nous connaissons une simple fonctionnalité de CMS, parmi le champ des possibilités offertes par le futur Drupal 8, qui sera au final une interface RESTful, le terme REST (Representational State Transfer) qu'on peut définir comme un "style architectural" reposant sur le protocole HTTP propre au Web. En effet, il permet d'analyser et de modifier une ressource (repérée par l'URI, ou Universal Resource Identifier, et non l'URL qui n'est parfois qu'une simple adresse de cette ressource) en utilisant une représentation de celle-ci. Cette méthode élargit ainsi les possibilités de formats de sortie pour ne plus délivrer uniquement du format HTML sous forme de page, mais tout autre format non-HTML, comme du XML, du JSON, un flux RSS, et même des informations d'une application SOAP, un protocole régulièrement utilisé pour les web services. L'objectif plus global étant clairement énoncé : "[...] for Drupal to truly embrace the future web".

Larry énumère bon nombre de facteurs dans son annonce officielle qui impliquent une extraction des données brutes, et non plus uniquement un retour HTML : l'utilisation massive des requêtes asynchrones pour mettre à jour une partie seulement d'une page web, l'explosion de l'Internet sur les smartphones, les analyses de données brutes d'un site. Dans son article "Drupal in the post-page era" datant du 1er novembre 2011, il argumente ce choix en affirmant qu'on doit aujourd'hui parler de réponse à une requête lorsqu'on parle du Web, et non pas de réponse sous forme de page HTML :

"Everything is not a page, destined for a known browser. Everything is a response to a request [...] In practice, the server may almost never generate an entire page from html tag to html tag. It requires leveraging all of the HTTP protocol, not just the tiny subset that browser HTML lets us access."

Dries Buytaert est apparemment d'accord avec ces propos puisqu'il confirme sur son blog que le but de l'initiative menée par Larry Garfield est de faire de Drupal une interface RESTful.

 

La question est bien entendue la suivante : comment compte-t-il s’y prendre ?

Il donne un élément de réponse dans la suite de l'introduction : "To do that, we must give Drupal a unified, powerful context system that supports smarter, context-sensitive, easily cacheable block-centric layouts and non-page responses using a robust unified plugin mechanism." C'est dans son annonce officielle sur son blog que le plan d'action nous donne l'objectif visé : "The solution here is to wrap the HTTP request into a single, extensible context object. That context object will act as a central gateway to information coming from the client (who may not be a user at all) as well as information we derive from it, such as the current node, current user, and so on."

C'est la requête HTTP dans sa totalité dont il parle ici, pour pouvoir ensuite l'utiliser comme bon nous semble, en ayant un format de sortie approprié au besoin, sans forcément récupérer un code HTML au bout. Et finalement, pour faire de Drupal un web service : "Then, Drupal doesn't just support web services: Drupal is a web service."

Pour cela, Larry propose dans son plan d'élaborer un "context system" qui sera une passerelle pour l'information provenant du client et des informations que l'on peut en tirer, et qui sera dans le core de Drupal 8, comme on peut l'apprendre sur la page "Add unified context system to core ". A l'heure actuelle, le projet s'appelle "Butler" et a pour but d'être implémenté sous Drupal 7 comme un module classique.

J'en arrive au point où je voulais en venir : l'apparition du célèbre framework Symfony dans le monde Drupal ! C'est sur la page "Rethinking WSCCI" que l'on apprend qu'après des mois de recherche et de nombreuses réticences sur des nouveaux concepts "context API" dans le but de gérer au mieux les requêtes HTTP dans leur globalité, il a été décidé d'un rapprochement majeur avec Symfony2. Plus précisément avec certains composants utilisés par Symfony2, qui font déjà ce que les développeurs qui travaillent sur ce projet cherchent à faire, leur force étant leur indépendance et leur extensibilité, deux avantages de la programmation orienté objet (POO),

 

(Petite parenthèse en ce qui concerne l'orienté objet :

Avec l'initiative menée par Larry Garfield décrite précédemment, le questionnement actuel de Drupal en terme de développement est plus que jamais l'aspect "orienté objet" (OO) de l'outil,  qui est encore et toujours son point faible. D’abord parce que Drupal étant initialement basé sur un code PHP procédural (Drupal est né sous PHP4), l'apparition de PHP5 qui introduit l’orienté objet n’a pas donné lieu à une refonte de la façon de penser, dans la même direction qu’ont pris dès le départ des frameworks comme Symfony et Zend – pour ne citer que les plus célèbres – qui eux utilisent à fond le concept de POO.

Pourquoi changer du procédural à l’orienté objet ? Parce que c’est clairement LA façon de faire qu’il faut adopter, selon le langage PHP même qui choisit de prendre cette direction en 2003.  En effet, c’est à partir de la version 5.0.0 Beta 1, sortie officiellement le 29 juin 2003, que PHP utilise le moteur de Zend appelé "Zend Engine 2", qui introduit le concept de classe et d’objet propre à la POO. On peut lire la justification de cette évolution majeure dans l'introduction de la page du site officiel de PHP, claire et précise : "Depuis PHP 5, le modèle objet a été réécrit pour permettre de meilleures performances et offrir plus de fonctionnalités. Cette réécriture a été une des modifications majeures par rapport à PHP 4. PHP 5 a donc un modèle objet complet." Plutôt sans appel non ?

Partout sur la toile la communauté de développeurs PHP approuve ce choix et continue d’en faire l’apologie. Le Site du Zéro introduit cette évolution dans sa page consacrée à la programmation orientée objet, comme ceci : "La principale raison de ce succès est dû à de nombreux avantages apportés par ce paradigme, comme une organisation plus cohérente de vos projets, une maintenance plus facile et une distribution de votre code plus aisée pour celui qui l'utilisera." Des forums se créent pour répondre à la problématique de la POO, et c'est une véritable communauté de développeurs OO qui se retrouve sur tous les forums des frameworks PHP, qui utilisent bien entendu le concept d'objet et de classe à travers des méthodes de conception du type MVC (Modèle Vue Contrôleur), pour n'en citer qu'une.

Les développeurs Drupal ont bien conscience de cette lacune reprochée au CMS, et ont voulu montrer que bien que Drupal n'utilisait pas de l'orienté objet à proprement parler, il y avait tout de même des concepts approchant ce système… Tout en admettant  (on était alors qu'en 2009) qu'une évolution vers un système orienté objet serait certainement mise en place : "In the future, as both PHP and Drupal become more mature, Drupal may increasingly adopt the native OOP features of PHP."

Pour faire le parallèle avec le framework PHP Symfony, Fabien Potencier, cofondateur de Sensio Labs et à l'origine de Symfony, confirme cette lacune fin 2011 en officialisant l'utilisation de "briques" Symfony dans la version 8 de Drupal (le classloader pour ne charger automatiquement que les classes nécessaires à la page, et l’HTTP Foundation pour ajouter au-dessus de la spécification HTTP une abstraction objet qui n’existe pas par défaut dans PHP) : "Drupal, conçu dans les années 2000, a un code vieillissant et dont la maintenance doit être rendue plus facile."

Tout ça pour dire que si Larry s’active pour faire changer Drupal dans sa prochaine version 8, c’est qu’il a de bonnes raisons de le faire !

Je ferme la parenthèse.)

 

Nous assistons actuellement à un vif débat au sujet de la migration de la structure Drupal actuelle vers une structure "ISO POO" avec PHP, c’est-à-dire assurer une interopérabilité technique,  en commençant par adopter la convention PSR-0 qui concerne les "namespace" pour une interopérabilité du mécanisme d'autoloading. Un article intéressant traite plus en détails de cette convention qui impose des "conditions sévères qu'il est nécessaire de respecter pour espérer avoir un droit de vote ou même de participation aux débats".

A noter que Larry Garfield avait anticipé ce changement, et n’hésite pas en novembre 2009 à demander des conseils au sein même du "PHP Standards Working Group" à propos des standards à adopter dans les futures versions de Drupal, en demandant si Drupal peut effectivement migrer vers une structure interopérable, ce qui semblait à l’époque un vaste chantier avec de nombreuses interrogations.

Entre-temps de l’eau a coulé sous les ponts, des recherches ont été effectuées, pour déboucher en août dernier sur un vrai projet, la preuve étant la création d’une page dédiée sur le site officiel : "Adopt PSR-0 namespace convention for core framework classes".

L’une des dernières préoccupations actuelles étant l’application de la convention PSR-0 dans le système de modules et de plugin de Drupal, discussion ouverte sur le "PHP Standards Working Group" par Larry Garfield qui s’implique décidément à fond dans sa tâche de leader, et datant du 16 janvier dernier.

Plus généralement, l'heure est encore à comprendre comment intégrer Symfony dans Drupal, et jusqu'à quel point.

 

Plutôt que de continuer sur ma lancée sur un sujet pour lequel il y a encore beaucoup de zones d'ombres, je préfère vous laisser sur votre faim (?) mais vous laisser avec quelques liens à la fin de cet article pour creuser le sujet et, pourquoi pas, participer par vous-même à l'évolution de Drupal !

Je termine par une citation de Dries Buytaert tirée d'une interview qui a eu lieu fin 2011, et qui va probablement être perçue très différemment selon les profils utilisateurs/développeurs de Drupal : "Some projects choose to maintain backwards compatibility, others do not. So far, Drupal as a project has chosen to break that. The advantage, however, is that we don't need to carry a lot of the old stuff. We can reinvent ourselves. We can continue to change Drupal so that it's the best possible platform. Other platforms that choose to support backward compatibility have a hard time innovating because they have to support old code."

Certains développeurs vont probablement grincer des dents en pensant aux sites à migrer sous Drupal 7 puis 8 et ainsi de suite, et à tout ce que ça implique en termes de prise de tête... D'autres penseront au contraire que c'est la meilleure solution pour coller aux besoins du Web au jour le jour, en se basant sur le fait qu'on dit en général qu'un site internet est amené à changer tous les deux ans, à peu près la durée entre deux versions majeures de Drupal, non ?

D'ailleurs, à la vitesse où les choses avancent, je reviendrai probablement sur cet article prochainement pour le mettre à jour :-)

 

Quelques liens :

L'annonce du système d'initiatives de Drupal 8 par Dries Buytaert : http://buytaert.net/drupal-2011-retrospective-and-2012-predictions

Les initiatives, avec à chaque fois leur leader et leur annonce respective : http://drupal.org/community-initiatives/drupal-core

 

Le projet "Web Services and Context Core Initiative " mené par Larry Garfield :

 

Plus d'informations sur l'architecture REST :