Différences

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

--- prog:theorie:api:whatisitapi [22/02/2021 18:31]
thierry [Le niveau 1 : plusieurs URIs, un seul verbe]
+++ 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 116: / Ligne 116: @@
 === Le niveau 2 : plusieurs URIs, plusieurs verbes et les codes retour ===
-Ce niveau de maturité ajoute l’utilisation sémantique des verbes (ou méthodes) et codes retours HTTP afin d’enrichir le niveau de protocole applicatif entre le client et le serveur. Même si la liste est plus longue (mais restreinte), les verbes GET, POST, PUT ou DELETE suffisent dans la grande majorité des cas à couvrir l’ensemble des besoins d’un système, en accord avec le principe CRUD ; soulignons quand même le dernier venu, PATCH, qui permet une modification partielle d’une ressource, contrairement à PUT qui impose le remplacement complet d’une ressource.
+Ce niveau de maturité ajoute l’utilisation sémantique des verbes (ou méthodes) et codes retours HTTP afin d’enrichir le niveau de protocole applicatif entre le client et le serveur.
-Si nous reprenons les exemples du niveau 1, l’utilisation des verbes et codes retour HTTP peuvent se faire ainsi :
+Même si la liste est plus longue (mais restreinte), les verbes GET, POST, PUT ou DELETE suffisent dans la grande majorité des cas à couvrir l’ensemble des besoins d’un système, en accord avec le principe CRUD ; soulignons quand même le dernier venu, PATCH, qui permet une modification partielle d’une ressource, contrairement à PUT qui impose le remplacement complet d’une ressource.
+Si nous reprenons les exemples du niveau 1, l’utilisation des verbes et codes retour HTTP peuvent se faire ainsi :
+<code html>
 POST /banking/accounts/1234 HTTP 1.1
 ...
@@ Ligne 125: / Ligne 127: @@
 <balance>1000.10</balance>
 </account>
+</code>
 pour la création d’un compte attaché au client 1234, et
+<code html>
 DELETE /banking/accounts/abcd-12 HTTP 1.1
 ...
+</code>
 pour la suppression du compte abcd-12.
@@ Ligne 138: / Ligne 142: @@
 Concernant les réponses du serveur suite à la demande de création, l’utilisation des codes retour HTTP permet d’apporter une sémantique claire au client ; si la réponse est
+<code html>
 HTTP/1.1 201 Created
 ...
@@ Ligne 146: / Ligne 150: @@
 ...
 </account>
+</code>
 le client en déduit que le compte a bien été crée et il peut en récupérer l’identifiant.
 Si la réponse du serveur est
+<code html>
 HTTP/1.1 404 Not Found
 ...
+</code>
 le client en déduit que le client n’existe pas parce qu’il a été supprimé avant la requête par exemple.
@@ Ligne 166: / 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 185: / 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 197: / Ligne 205: @@
 <balance>1000.10</balance>
 </account>
+</code>
 La réponse du serveur
+<code html>
 HTTP/1.1 201 Created
 ...
@@ Ligne 208: / 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.