Présentation de REST. Partie 2 : Communication entre un client et un serveur

Présentation de REST. Partie 1 : Qu'est-ce que REST ? Dans cette partie, nous allons approfondir la façon dont la communication se déroule entre un client et un serveur. En cours de route, nous découvrirons de nouveaux termes et les expliquerons. Pour nous assurer que tout est clair, nous analyserons la communication client-serveur en utilisant une application RESTful comme exemple. Supposons que nous développions une application Web qui stocke des informations sur les clients et leurs commandes. En d'autres termes, notre système est capable d'effectuer des opérations sur certaines entités : les créer, les modifier, les supprimer et afficher des informations à leur sujet. Ces entités seront :

• clients (clients)
• commandes (commandes clients)
• articles (produits)

Dans une architecture RESTful, les clients envoient des requêtes à un serveur pour récupérer ou modifier des données, puis les serveurs envoient aux clients des réponses à leurs requêtes.

Demandes

Les demandes des clients sont presque toujours effectuées à l'aide du protocole HTTP. En général, les requêtes HTTP se composent de plusieurs composants :

• Méthode HTTP
• entête
• URI
• corps de la demande

Ci-dessous, nous examinerons chaque composant plus en détail.

URI et ressources

Les données que les clients reçoivent ou modifient via des requêtes sont appelées ressources. La communication client-serveur consiste à manipuler des ressources. Dans REST, les ressources sont tout ce à quoi vous pouvez donner un nom. Dans un sens, ils sont comme des classes en Java. En Java, nous pouvons créer une classe pour n'importe quoi. Donc dans REST, une ressource peut être n'importe quoi : un utilisateur, un document, un rapport, une commande. Il peut s'agir soit d'une abstraction d'une entité, soit de quelque chose de spécifique, par exemple une image, une vidéo, une animation ou un fichier PDF. Dans notre exemple, nous avons 3 ressources :

• clients (clients)
• commandes (commandes clients)
• articles (produits)

Les clients envoient des requêtes à des emplacements de ressources appelés points de terminaison. En termes simples, un point de terminaison est comme une adresse sur le réseau. En approfondissant, on peut dire qu'un endpoint est un URI, c'est-à-dire une séquence de caractères qui identifie une ressource abstraite ou physique. Identifiant de ressource uniforme (URI) Parfois, un point de terminaison, ou URI, est appelé un chemin, c'est-à-dire le chemin d'accès à une ressource. Pour les besoins de cet article, nous utiliserons le terme URI. Chaque ressource spécifique doit avoir un URI unique. Le développeur du serveur est responsable de s'assurer que chaque ressource a toujours sa propre URI. Dans notre exemple, nous sommes les développeurs, nous allons donc le faire comme nous le savons. Tout comme il est souvent d'usage d'attribuer des identifiants numériques comme clés primaires dans une base de données relationnelle, chaque ressource a également son propre identifiant dans REST. L'ID de ressource dans REST correspond souvent à l'ID de l'enregistrement dans la base de données qui stocke les informations sur la ressource. Les URI REST commencent habituellement par la forme plurielle d'un nom décrivant une ressource. Par exemple, "

• /customers — URI de tous les clients disponibles
• /customers/23 — URI d'un client spécifique, c'est-à-dire le client avec ID=23
• /customers/4 — URI d'un client spécifique, c'est-à-dire le client avec ID=4.

Mais ce n'est pas tout. Nous pouvons étendre l'URI en ajoutant des commandes :

• /customers/4/orders — URI de toutes les commandes passées par le client n° 4
• /customers/1/orders/12 — URI de la commande n° 12 effectuée par le client n° 1.

Si nous continuons l'expansion en ajoutant plus de produits, nous obtenons :

• /customers/1/orders/12/items — URI de la liste de tous les produits de la commande n° 12 passée par le client n° 1.

Au fur et à mesure que nous ajoutons des niveaux d'imbrication, l'important est de rendre les URI intuitives.

Méthode HTTP

La méthode HTTP est une séquence de caractères quelconques (à l'exception des caractères de contrôle et des délimiteurs), qui indique l'opération principale effectuée sur la ressource. Il existe plusieurs méthodes HTTP courantes. Nous allons lister ceux qui sont le plus souvent utilisés dans les services RESTful :

• GET - Obtenir des informations sur une ressource particulière (via son ID) ou sur une collection de ressources
• POST — Créer une nouvelle ressource
• PUT — Modifier une ressource (via son ID)
• DELETE — Supprimer une ressource (via son ID)

En-têtes

Les requêtes, ainsi que les réponses, contiennent des en-têtes HTTP. Ils véhiculent des informations supplémentaires sur la requête (ou la réponse). Les en-têtes sont des paires clé-valeur. Vous pouvez consulter la liste des en-têtes les plus courants sur Wikipedia . Comme pour REST, les clients envoient souvent un en-tête "Accepter" dans les requêtes au serveur. Cet en-tête est nécessaire pour indiquer au serveur le format dans lequel le client s'attend à recevoir une réponse. Différents formats sont donnés dans une liste de types MIME. MIME (Multipurpose Internet Mail Extensions) est une spécification permettant d'encoder des informations et de formater des messages afin qu'ils puissent être envoyés sur Internet. Chaque type MIME se compose de deux parties séparées par une barre oblique - un type et un sous-type. Exemples de types MIME pour différents types de fichiers :

• texte — texte/plain, texte/css, texte/html
• image — image/png, image/jpeg, image/gif
• audio — audio/wav, audio/mpeg
• vidéo — vidéo/mp4, vidéo/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream

Par exemple, une requête peut avoir un en-tête comme celui-ci :

Accept:application/json

Cet en-tête indique au serveur que le client s'attend à recevoir une réponse au format JSON.

Corps de la requête

C'est le message envoyé par le client au serveur. Le fait que la requête ait un corps ou non dépend du type de requête HTTP. Par exemple, les requêtes GET et DELETE ne contiennent généralement aucun corps de requête. Mais les requêtes PUT et POST le peuvent - cela dépend simplement de l'objectif de la requête. Après tout, pour recevoir et/ou supprimer des données à l'aide d'un ID (qui est passé dans l'URL), vous n'avez pas besoin d'envoyer des données supplémentaires au serveur. Mais pour créer une nouvelle ressource (via une requête POST), vous devez envoyer la ressource. Il en va de même pour la modification d'une ressource existante. Dans REST, le corps de la requête est le plus souvent envoyé au format XML ou JSON. Le format JSON est le plus courant. Supposons que nous souhaitions envoyer une requête au serveur afin de créer une nouvelle ressource. Si vous n'avez pas oublié, nous avons pris l'exemple d'une application qui gère les commandes des clients. Disons que nous voulons créer un nouveau client. Dans notre cas, nous stockons les informations client suivantes : nom, email, numéro de téléphone. Ensuite, le corps de la requête pourrait être le JSON suivant :

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Assemblage des demandes

Nous avons donc examiné ce qui pourrait se trouver dans une demande client. Nous allons maintenant donner quelques exemples de requêtes accompagnés de descriptions

Réponses

Disons quelques mots sur les réponses du serveur. Une réponse comprend généralement les parties suivantes :

• Code de réponse
• en-têtes
• corps de réponse

En général, les en-têtes de réponse ne sont pas très différents des en-têtes de requête. De plus, certains en-têtes sont utilisés à la fois dans les réponses et les demandes. Je pense que tout est également clair concernant le corps de la requête. Le corps renvoie souvent des informations demandées par le client. Les informations renvoyées en réponse aux requêtes GET peuvent également être au format JSON. Mais la dernière partie est un peu plus intéressante.

Codes de réponse HTTP

Considérons les codes de réponse HTTP plus en détail. Un code d'état HTTP fait partie de la première ligne d'une réponse du serveur aux requêtes effectuées via le protocole HTTP. C'est un nombre entier composé de trois chiffres décimaux. Le premier chiffre indique la classe du code d'état de la réponse. Le code de réponse est généralement suivi d'une phrase explicative en anglais, séparée par un espace. Cette phrase est une raison lisible par l'homme pour la réponse. Exemples:

• 201 créé
• 401 Non autorisé
• 507 Stockage insuffisant

Le code de réponse indique au client le résultat de la demande et lui permet de déterminer les actions à entreprendre ensuite. Les codes de réponse sont divisés en plusieurs classes ou groupes :

• 1XX — Informationnel
• 2XX — Ces codes indiquent que la demande du client a été reçue et traitée avec succès
• 3XX — Ces codes informent le client qu'une demande supplémentaire, généralement adressée à un URI différent, doit être effectuée afin de mener à bien l'opération.
• 4XX — Erreur client. De tels codes peuvent résulter d'une requête mal composée. Un autre exemple est le code bien connu "404 Not Found", qui peut se produire lorsqu'un client demande une ressource inexistante
• 5XX — Erreur de serveur. Ces codes sont retournés au client si le serveur est responsable de l'échec de l'opération

Présentation de REST. Partie 3 : Création d'un service RESTful sur Spring Boot