Hypermédia et htmx : faire évoluer une interface depuis le serveur

Vous filtrez une liste de factures. Le navigateur peut demander des données JSON puis reconstruire les lignes, ou recevoir du serveur le fragment HTML prêt à afficher. htmx facilite la seconde approche. Elle permet de garder une grande partie de la logique de présentation côté serveur, tout en actualisant seulement la zone concernée de la page.

Le serveur peut fournir l'interface et ses actions

Dans une application riche en JavaScript, le client connaît souvent la forme des données et la manière de les afficher. Il décide aussi quand appeler l'API et quelles actions proposer. Cette organisation convient à de nombreux usages, mais elle peut dupliquer certaines règles de présentation entre client et serveur.

Une interface hypermédia transmet des données avec leurs liens et leurs formulaires. Avec HTML, ces contrôles sont déjà compris par le navigateur : un lien ouvre une destination et un formulaire décrit une saisie.

htmx actualise une partie de la page

htmx ajoute des attributs HTML qui associent un événement à une requête et à une zone de remplacement. Lorsqu'un utilisateur change le filtre des factures, le navigateur envoie la demande ; le serveur renvoie les lignes correspondantes ; htmx les place dans la page.

Le serveur continue donc à produire le balisage. Le navigateur évite un rechargement complet et conserve une interaction fluide. L'équipe peut maintenir les règles d'affichage dans les mêmes gabarits que le reste des pages.

Le livre Hypermedia Systems, publié en 2023 par Carson Gross, Adam Stepinski et Deniz Akşimşek, développe cette organisation. Il décrit également Hyperview, qui applique un principe de représentation hypermédia à une application mobile native.

La simplification concerne surtout la présentation

Le gain attendu est de réduire le code qui transforme les réponses de l'API en éléments d'interface. Pour une application composée principalement de listes, de formulaires et de consultations, cette réduction peut faciliter les modifications.

Le serveur reste responsable des règles métier et de la validation. Le HTML représente ces règles pour l'utilisateur ; il ne remplace pas les données de référence. Un champ masqué ou une action absente de l'écran ne suffit pas à interdire une requête.

Le rendu serveur peut aussi fournir un contenu visible dès la première réponse. Les applications riches peuvent obtenir ce résultat par d'autres mécanismes de rendu serveur ou de prérendu. Le choix dépend de la façon dont l'ensemble est construit, pas seulement du framework.

La couche de présentation prépare les liens et les formulaires

Cette couche traduit les données métier en ce que reçoit le client. Pour une facture en brouillon, elle peut proposer un formulaire de modification et une action de validation. Pour une facture déjà émise, elle offre d'autres possibilités.

Chaque contrôle doit préciser les informations nécessaires :

• Le lien indique sa destination et un libellé compréhensible.
• Le formulaire décrit les champs, leurs contraintes et la façon de le soumettre.
• La réponse signale les erreurs de saisie ou les conflits avec l'état actuel.
• Le serveur vérifie de nouveau les droits et les règles lorsque la demande arrive.

Les formulaires HTML natifs utilisent principalement GET et POST. Des méthodes comme PUT ou DELETE nécessitent un mécanisme complémentaire côté client, par exemple les attributs de htmx. Le contrat doit décrire ce fonctionnement sans supposer qu'il appartient au HTML de base.

Prévoir les consommateurs qui attendent du JSON

Une interface HTML pratique pour un humain ne constitue pas automatiquement le meilleur contrat pour un logiciel tiers. Vous pouvez proposer une API séparée ou plusieurs représentations d'une même ressource.

Dans le second cas, l'en-tête Accept permet au client d'indiquer le format attendu : HTML pour l'affichage, JSON pour le programme. C'est la négociation de contenu. Le JSON peut lui aussi contenir des liens et des actions, dans un format documenté.

Je privilégie cette représentation commune lorsque les deux usages partagent réellement le même contrat. Hypermedia Systems recommande plutôt de séparer les interfaces destinées aux humains et aux machines. Une API distincte devient pertinente si leurs besoins de données, de stabilité ou de performance divergent.

La contrainte « sans état » de REST demande que chaque requête apporte les informations nécessaires pour être comprise. Elle n'interdit pas de conserver les données métier, et elle ne prescrit pas de placer tous les identifiants dans l'URL.

Conserver un client riche lorsque l'interaction le demande

Un éditeur hors ligne, un outil de dessin ou une interface manipulant beaucoup d'état local peut avoir besoin d'une logique importante dans le navigateur. Renvoyer chaque mouvement au serveur serait alors pénalisant.

Pour choisir, examinez un parcours représentatif : quelle part du comportement dépend des données serveur, quelle part doit rester immédiate et locale, et que se passe-t-il si le réseau disparaît ? Vous pouvez combiner des écrans rendus côté serveur et des composants riches là où ils sont utiles.

Le bénéfice de l'hypermédia vient des contrôles que le client sait réellement suivre. Le même principe peut servir à un agent parcourant une API, à condition de lui donner un vocabulaire compréhensible et des droits adaptés.

Sources

• C. Gross, A. Stepinski & D. Akşimşek, Hypermedia Systems, 2023.
• HATEOAS, essai htmx.
• Hyperview.
• R. T. Fielding, REST APIs must be hypertext-driven, octobre 2008.
• R. T. Fielding, thèse, 2000 — chapitre 5.