Article

REST et CQRS : relier les lectures de l’API aux décisions métier

GET sert souvent les vues de lecture, tandis que les écritures demandent une décision métier. REST et CQRS se combinent sans imposer le même découpage.

par
La fiche d'une commande réunit son contenu, le nom du client et son état de livraison. Son annulation suit pourtant des règles qui appartiennent au domaine des commandes. L'API peut présenter ces informations ensemble tout en dirigeant la demande d'annulation vers le modèle qui sait la valider. C'est une manière de combiner REST et CQRS.

Deux choix qui se complètent

CQRS sépare les modèles utilisés pour les commandes et les lectures. REST définit des contraintes d'architecture pour les échanges entre clients et serveurs. L'un n'impose pas l'autre.

Dans une API HTTP, un GET peut être servi par le modèle de lecture. Une demande de changement, portée par POST, PUT, PATCH ou DELETE, peut déclencher une commande métier.

Cette correspondance aide à organiser le code, mais elle n'est pas une équivalence stricte. Une recherche complexe peut utiliser POST sans devenir une décision métier. Il faut alors préciser ses propriétés, notamment de cache et de reprise.

Respecter le sens des méthodes HTTP

Un GET ne doit pas demander une action comme supprimer une facture. Des robots, des caches ou des mécanismes de préchargement peuvent consulter une adresse sans intention de déclencher cette action.

Le serveur peut néanmoins écrire un journal d'accès : cet effet technique ne change pas le sens de la lecture demandée. La sûreté de la méthode porte sur ce que le client demande de faire.

L'idempotence est une autre propriété. PUT et DELETE la promettent ; une opération PATCH peut être conçue comme idempotente, mais ne l'est pas automatiquement.

Concevoir les ressources pour leurs consommateurs

Un agrégat regroupe les données dont le domaine protège les règles ensemble. Une ressource d'API représente ce que le client consulte ou manipule. Les deux peuvent correspondre, sans que ce soit obligatoire.

La fiche d'une commande peut assembler plusieurs sources pour éviter au client de réaliser de nombreux appels. Sa modification ne signifie pas pour autant que tous ces éléments peuvent être changés dans une seule opération.

Les actions disponibles doivent indiquer leur portée : modifier une adresse, annuler une commande ou demander un remboursement sont des intentions différentes.

Relier une modification à la version qui a été lue

Le client peut avoir lu un état ancien. Un contrôle de concurrence permet au serveur de refuser une modification fondée sur une version dépassée.

Le contrat peut utiliser un champ de révision ou un validateur HTTP avec If-Match. Une précondition HTTP non satisfaite conduit à 412 ; un conflit applicatif peut être décrit par 409. L'article sur les écritures concurrentes détaille la reprise.

Le validateur doit porter sur la représentation ou les données réellement protégées. Avec PUT, HTTP impose aussi des conditions à l'émission d'un validateur dans la réponse si le serveur a transformé les données reçues avant de les enregistrer. Cela ne rend pas obligatoire un champ de révision dans toutes les API.

Dire ce qui est terminé et ce qui reste en attente

Une commande peut être enregistrée alors que sa projection de lecture n'est pas encore actualisée. La réponse à l'écriture peut fournir l'état confirmé ou un moyen de le consulter, en précisant le délai éventuel de la vue.

202 Accepted signifie que la demande a été acceptée pour traitement, sans que celui-ci soit achevé. Il convient à un travail encore en cours, pas automatiquement à toute projection en retard.

Un lien de suivi et un statut explicite permettent au client de distinguer l'acceptation de la demande, sa réussite métier et son apparition dans une liste.

Présenter les actions possibles sans déplacer leur validation

Une représentation peut proposer « annuler » lorsque la commande semble encore annulable. Ces contrôles hypermédia aident le client à découvrir le parcours.

Le serveur vérifie de nouveau les droits et l'état à l'exécution. Entre la lecture et l'appel, la commande peut avoir été expédiée. Le client doit donc comprendre aussi le refus.

Une API claire relie ainsi trois éléments : l'information disponible, la décision demandée et son résultat. Le modèle interne reste libre d'évoluer tant que ce contrat est respecté.

Sources

cqrs rest hypermedia api

Partager

Explorer

Sur le même sujet

Choisis dans l’index d’après les étiquettes de cet article — les plus proches d’abord, hors de sa série. Rien n’est écrit à la main : un article publié demain avec les mêmes étiquettes y prendra place.

Laisser un commentaire

Elle n'est jamais affichée ni publiée. Elle sert à regrouper vos commentaires et, si vous vous inscrivez un jour avec elle, à vous les rendre.

Votre commentaire sera relu avant d'être publié.