Différences

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

--- prog:theorie:api:whatisitapi [22/02/2021 18:27]
thierry [Le niveau zéro : POX et XML-RPC]
+++ 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/]]
 === Niveau 0 : POX et XML-RPC ===
@@ Ligne 80: / Ligne 81: @@
 HTTP y sert uniquement de moyen pour véhiculer des appels au serveur applicatif. Le client est tenu de connaître précisément l’implémentation technique de l’application, d’où un fort couplage entre les 2.
-=== Le niveau 1 : plusieurs URIs, un seul verbe ===
+=== Niveau 1 : plusieurs URIs, un seul verbe ===
-Ce niveau de maturité consiste en l’utilisation de plusieurs URIs comme points d’entrée du système d’information mais d’un seul verbe HTTP(usuellement GET ou POST) ; c’est le premier pas vers une architecture REST de niveau 3. Les domaines applicatifs ou techniques du système sont éclatés en plusieurs URIs, par exemple /banking/clients pour la partie clients et /banking/accounts pour la partie comptes.
+Ce niveau de maturité consiste en l’utilisation de plusieurs URIs comme points d’entrée du système d’information mais d’un seul verbe HTTP(usuellement GET ou POST) ; c’est le premier pas vers une architecture REST de niveau 3. Les domaines applicatifs ou techniques du système sont éclatés en plusieurs URIs, par exemple ''/banking/clients'' pour la partie clients et ''/banking/accounts'' pour la partie comptes.
 Ce modeste pas évite à un client (un agent) de connaître l’ensemble des domaines applicatifs du système (comme c’était le cas au niveau 0) s’il ne sert qu’à traiter un domaine unique par exemple. De plus, cette différentiation d’URIs par domaine applicatif apporte une sémantique aux points d’entrée du système ce qui est, une des grandes forces du style d’architecture REST.
-Pour connaître les comptes d’un client, il suffit alors d’appeler la ressource /banking/accounts?client_id=1234. La création d’un compte pour un client donné pourra se faire au moyen de la ressource /banking/accounts/create?client_id=1234 en ajoutant dans le corps du message les détails, en XML par exemple, du compte à créer pour ce client :
+Pour connaître les comptes d’un client, il suffit alors d’appeler la ressource ''/banking/accounts?client_id=1234''. La création d’un compte pour un client donné pourra se faire au moyen de la ressource ''/banking/accounts/create?client_id=1234'' en ajoutant dans le corps du message les détails, en XML par exemple, du compte à créer pour ce client :
+<code html>
 POST /banking/accounts/create?client_id=1234 HTTP 1.1
 ...
@@ Ligne 93: / Ligne 94: @@
 <balance>1000.10</balance>
 </account>
+</code>
 La réponse du serveur en cas de succès pourra être :
+<code html>
 HTTP/1.1 200 OK
 ...
@@ Ligne 103: / Ligne 105: @@
 ...
 </account>
+</code>
 On peut voir que le corps du message contient les informations complètes du compte nouvellement créé. Le client peut alors s’il le désire supprimer le compte car il possède maintenant son identifiant :
+<code html>
 POST /banking/accounts/delete?id=abcd-12 HTTP 1.1
 ...
+</code>
 Ces exemples montrent un allègement de complexité dans la manière d’accéder au système d’information dès lors que la syntaxe des URIs est connue ainsi que le langage XML du domaine applicatif qui se trouve être réduit du fait de l’éclatement des URIs par rapport au niveau 1.
@@ Ligne 113: / 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 122: / 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 135: / 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 143: / 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 163: / 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 182: / 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 194: / Ligne 205: @@
 <balance>1000.10</balance>
 </account>
+</code>
 La réponse du serveur
+<code html>
 HTTP/1.1 201 Created
 ...
@@ Ligne 205: / 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.
+===== Sources et ressources =====
+  * [[https://architecturelogicielle.wordpress.com/2013/04/25/le-modele-de-maturite-de-richardson/|Le modèle de maturité de Richardson]]