Le modèle de maturité de Richardson est un modèle de maturité proposé en 2008 par Leonard Richardson, qui classe les API Web en fonction de leur adhésion et de leur conformité à chacun des quatre niveaux du modèle. L'objectif de la recherche du modèle tel qu'énoncé par l'auteur était de découvrir la relation entre les contraintes de REST et d'autres formes de services Web.
Il divise les principales parties de la conception RESTful en trois étapes : l'identification des ressources (URI), les verbes HTTP et les contrôles hypermédias (par exemple les hyperliens).
Ce modèle a été cité comme utile pour évaluer la qualité de la conception d'API Web particulièrement RESTful (même s'il ne se limite pas au REST seul) et critiqué pour ne pas avoir abordé la manière dont un système pourrait atteindre les niveaux de maturité les plus élevés du modèle, ainsi que pour avoir pris en compte un nombre limité d'attributs de qualité.
Principe Le modèle de maturité de Richardson peut être utilisé pour déterminer dans quelle mesure une architecture de service Web adhère aux principes REST. Il catégorise une API Web en quatre niveaux (de 0 à 3), chaque niveau supérieur correspondant à une adhésion plus complète à la conception REST. Le niveau suivant contient également toutes les caractéristiques du précédent.
D'autres systèmes de classification pour la conception de services API Web existent également, tels que CoHA et WS 3.
Niveaux
Niveau 0 : le marais du POX Le niveau le plus bas du modèle décrit une API Web avec un seul URI (généralement POST en HTTP) acceptant toute la gamme d'opérations prises en charge par le service. Les ressources sous cette forme ne peuvent pas être bien définies. La messagerie est effectuée au format XML, JSON ou d’autres formats texte. Il s'agit de services RPC POX typiques et de nombreux services SOAP.
Les systèmes de niveau zéro ne sont pas classés comme RESTful. +Exemples d'API de niveau 0 URI Verbe HTTP Opérations /bookingService POST Récupérer des destinations/hôtels/chambres ; ajouter/annuler une réservation ; etc. /newsFeedService POST Obtenir toutes les nouvelles ; obtenir toutes les nouvelles dans la catégorie spécifiée ; obtenir toutes les nouvelles d'un média spécifié ; etc.
Niveau 1 : ressources Introduit des ressources et permet des requêtes pour des URI individuels (toujours généralement POST) pour des actions distinctes au lieu d'exposer un point de terminaison universel (API). Les ressources de l'API sont encore généralisées mais il est possible d'identifier la portée de chacune d'entre elles.
La conception de niveau 1 n'est pas RESTful, mais elle organise l'API dans le sens où elle le devient. +Exemples d'API de niveau 1 URI Verbe HTTP Opération /bookingDestinations POST Récupérer les destinations /bookingRéservations POST Ajouter/annuler des réservations /bookingRooms POST Ajouter/annuler des demandes spéciales à une réservation /bookingFeedback POST Laisser les commentaires
Niveau 2 : verbes HTTP Le système commence à utiliser les verbes HTTP. Cela permet une spécialisation plus poussée de la ressource et réduit ainsi la fonctionnalité de chaque opération individuelle au sein du service. La séparation principale à ce niveau consiste à diviser une ressource donnée en deux – une requête pour obtenir uniquement des données (GET), l'autre pour modifier les données (POST). Une granularisation supplémentaire est également possible. Les requêtes GET récupèrent uniquement les données, les appels POST/PUT introduisent de nouvelles données et mettent à jour les données existantes, et les requêtes DELETE suppriment ou invalident les actions précédentes. L’un des inconvénients de la fourniture d’un service distribué avec plus de verbes GET et POST par ressource pourrait être la complexité croissante de l’utilisation d’un tel système.
+Exemples d'API de niveau 2 URI Verbe HTTP Opération /destinations GET Récupérer les destinations /reservations GET Obtenir des réservations selon certains critères /reservations POST Ajouter/annuler des réservations /rooms POST Demander des extras pour la chambre /rooms DELETE Supprimer les extras de la chambre
Niveau 3 : contrôles hypermédias Le dernier niveau introduit la représentation hypermédia. Également appelés HATEOAS (Hypermedia As The Engine of Application State), ce sont des éléments intégrés dans les messages de réponse des ressources qui peuvent établir une relation entre les entités de données individuelles renvoyées et transmises aux API. Par exemple, une requête GET adressée à un système de réservation d'hôtel peut renvoyer un certain nombre de chambres disponibles ainsi que des liens hypertexte (il s'agissait de contrôles d'hyperliens HTML au début du modèle) permettant au client de réserver des chambres spécifiques.
Il s’agit du dernier niveau du modèle de maturité de Richardson.
Requête : GET /room/?customerId=1&date=10-11-2020&hotelCode=ASTORIA HTTP/1.1 Réponse : { customerId: "1", reservations: [{room: "102", checkin: "10-11-2020", checkout: "11-14-2020", price: "100", href: "https://localhost:8080/room/102"}]
Références
Catégorie:Méthode de développement logiciel Catégorie:Pages avec des traductions non relues