Différences

Ci-dessous, les différences entre deux révisions de la page.

--- prog:theorie:api:whatisitapi [22/02/2021 18:33]
thierry [Le niveau 2 : plusieurs URIs, plusieurs verbes et les codes retour]
+++ prog:theorie:api:whatisitapi [18/10/2022 11:29] (Version actuelle)
thierry ↷ Page déplacée de prog:api:whatisitapi à prog:theorie:api:whatisitapi
@@ Ligne 29: / Ligne 29: @@
 Il doit être possible d’utiliser les implémentations standards de cache HTTP.
-==== Moèle de maturité de Richardson ====
+==== Modèle de maturité de Richardson ====
   * Source : [[https://architecturelogicielle.wordpress.com/2013/04/25/le-modele-de-maturite-de-richardson/]]
@@ Ligne 171: / Ligne 171: @@
 Au niveau 2, le client doit connaître à l’avance l’ensemble des URIs correspondant aux différentes fonctionnalités du système ainsi que les actions possibles sur ces URIs (les méthodes HTTP). En somme, le client doit être au courant des requêtes possibles au fur et à mesure de son parcours au sein de l’applicatif : il doit connaître à l’avance les états applicatifs possibles du système.
-Au niveau 3, le client découvre pas à pas ce qu’il lui est permis de faire au niveau de l’application et ce, grâce au hypermédias. Nous sommes déjà familiarisés avec cette notion lorsque nous naviguons sur le Web : chaque page HTML affiche des liens vers d’autres pages. Ces dernières ne sont en fait que les prochains états de l’application (du site) que nous pouvons explorer à partir de la page courante. Dans REST, ce principe est appelé HATEOAS pour illustrer que les liens hypermédias nous guident d’état en état applicatif sans que nous les connaissions à l’avance.
+Au niveau 3, le client découvre pas à pas ce qu’il lui est permis de faire au niveau de l’application et ce, grâce au hypermédias.
+Nous sommes déjà familiarisés avec cette notion lorsque nous naviguons sur le Web : chaque page HTML affiche des liens vers d’autres pages. Ces dernières ne sont en fait que les prochains états de l’application (du site) que nous pouvons explorer à partir de la page courante. Dans REST, ce principe est appelé HATEOAS pour illustrer que les liens hypermédias nous guident d’état en état applicatif sans que nous les connaissions à l’avance.
 Reprenons nos exemples.
 Pour créer un compte pour le client 1234, le client commencera par en obtenir la description (GET) :
+<code html>
 GET /banking/clients/1234 HTTP 1.1
+</code>
 Le serveur renvoie alors
+<code html>
 HTTP/1.1 200 OK
 ...
@@ Ligne 190: / Ligne 192: @@
 <link rel="/banking/accounts" uri="/banking/accounts/1234">
 </client>
+</code>
-Le tag link représente un lien hypermédia en spécifiant le domaine applicatif « comptes du client » avec l’attribut rel ainsi que l’URI correspondante /banking/accounts/1234.
+Le tag link représente un lien hypermédia en spécifiant le domaine applicatif « comptes du client » avec l’attribut rel ainsi que l’URI correspondante ''/banking/accounts/1234''.
 Ainsi, les modifications d’URI coté serveur n’impacteront jamais le client qui ne doit juste connaître la signification, la sémantique des valeur d’attribut rel.
 De plus, l’ajout ou la suppression de tags link auto-documente les réponses du serveur avec les fonctionnalités accessibles depuis une réponse.
-Si le client décide d’atteindre la ressource /banking/accounts/1234 pour créer un compte, il émettra la même requête qu’au niveau 2 mais sans avoir eu besoin de connaître l’URI au préalable :
+Si le client décide d’atteindre la ressource ''/banking/accounts/1234'' pour créer un compte, il émettra la même requête qu’au niveau 2 mais sans avoir eu besoin de connaître l’URI au préalable :
+<code html>
 POST /banking/accounts/1234 HTTP 1.1
 ...
@@ Ligne 202: / Ligne 205: @@
 <balance>1000.10</balance>
 </account>
+</code>
 La réponse du serveur
+<code html>
 HTTP/1.1 201 Created
 ...
@@ Ligne 213: / Ligne 217: @@
 <link rel="self" uri="/banking/accounts/abcd-12">
 </account>
+</code>
 offre un lien vers la ressource créée que le client pourra utiliser pour supprimer le compte à l’aide d’un DELETE.