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

Partie 1 : Qu'est-ce que REST Dans cette partie, nous examinerons de plus près comment la communication se produit entre le client et le serveur. En cours de route, nous révélerons de nouveaux termes et leur donnerons des explications. Pour que tout soit clair, nous analyserons la communication client-serveur en utilisant l'exemple d'une application RESTful. Disons que nous développons une application Web capable de stocker des informations sur les clients et leurs commandes. Ceux. notre système est capable de manipuler certaines entités : les créer, les éditer, les supprimer et fournir des informations à leur sujet. Ces entités seront :

• clients - clients ;
• commandes - commandes des clients ;
• articles - marchandises.

Dans l'architecture REST, les clients envoient des requêtes au serveur pour obtenir ou modifier des données, et les serveurs envoient des réponses aux clients à leurs requêtes.

Demandes

Les demandes des clients sont presque toujours effectuées via HTTP. En général, les requêtes HTTP se composent de plusieurs éléments :

• Méthode HTTP ;
• titre;
• URI ;
• corps de la demande.

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

URI et ressources

Les données que les clients obtiennent ou modifient via des demandes sont appelées ressources. La base de l'interaction client-serveur est la manipulation des ressources. Les ressources dans REST sont tout ce qui peut recevoir un nom. Dans un sens, ce sont comme des classes en Java. En Java, nous pouvons créer une classe pour n'importe quoi. C'est la même chose en REST : une ressource peut être n'importe quoi : un utilisateur, un document, un rapport, une commande. Tout cela peut être soit une abstraction d'une entité, soit quelque chose de concret, par exemple un fichier - une image, une vidéo, une animation, un fichier PDF. Pour notre exemple, nous avons 3 ressources :

• clients - clients ;
• commandes - commandes des clients ;
• articles - marchandises.

Les clients envoient des requêtes à ce qu'on appelle des points finaux, ou points finaux. Pour le dire très simplement, un point de terminaison est quelque chose comme une adresse sur le réseau. Pour aller plus loin, un point de terminaison est un URI : une séquence de caractères qui identifie une ressource abstraite ou physique. Uniform Resource Identifier - un identifiant de ressource unifié. Parfois, le point de terminaison, ou URI, est appelé chemin – 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. La responsabilité de garantir que chaque ressource possède toujours son propre URI incombe au développeur du serveur. Dans notre exemple, nous sommes les développeurs, nous allons donc le faire comme nous le savons. Tout comme dans une base de données relationnelle, il est souvent d'usage de définir la clé primaire sur un certain identifiant numérique, dans REST, chaque ressource possède son propre identifiant. Il arrive souvent que l'ID d'une ressource dans REST corresponde à l'ID de l'enregistrement de la base de données dans laquelle sont stockées les informations sur cette ressource. Les URI REST commencent généralement par la forme plurielle d'un nom qui décrit une ressource. Par exemple, du mot clients. Ensuite, un identifiant est indiqué par une barre oblique - l'identifiant d'un client spécifique. Exemples:

• /clients - URI de tous les clients existants ;
• /clients/23 - URI d'un client spécifique, à savoir le client avec ID=23 ;
• /clients/4 - URI d'un client spécifique, à savoir le client avec ID=4.

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

• /clients/4/orders — URI de toutes les commandes du client n°4 ;
• /clients/1/orders/12 - URI de la commande n°12 du client n°1.

Si nous continuons cette chaîne et ajoutons des marchandises, nous obtenons :

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

Avec les niveaux d’imbrication, la clé est de rendre les URI intuitifs.

Méthode HTTP

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

• GET - utilisé pour obtenir des informations sur une ressource spécifique (via un identifiant) ou une collection de ressources ;
• POST - utilisé pour créer une nouvelle ressource ;
• PUT - utilisé pour modifier une ressource (via ID) ;
• DELETE - utilisé pour supprimer une ressource (via ID).

Rubriques

Les requêtes, ainsi que les réponses, contiennent des en-têtes HTTP. Ils envoient des informations supplémentaires sur la demande (ou la réponse). Les en-têtes sont des paires clé-valeur. Vous pouvez lire la liste des rubriques les plus courantes sur la page Wikipédia . Avec REST, les clients peuvent souvent envoyer un en-tête Accept dans leur requête au serveur. Il est nécessaire d'indiquer au serveur dans quel format le client s'attend à recevoir une réponse de sa part. Différentes options de format sont présentées dans la liste dite des types MIME. MIME (MultiPurpose Internet Mail Extensions) est une spécification permettant de coder 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.

Au total, la requête peut avoir l'en-tête suivant :

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 demande

Un message envoyé par le client au serveur. Le fait qu'une 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 PUT et POST peuvent contenir : tout dépend de l’objectif fonctionnel du type de requête. Après tout, pour recevoir des données et les supprimer par identifiant (qui est transmis dans l'URL), vous n'avez pas besoin d'envoyer des données supplémentaires au serveur. Mais pour créer une nouvelle ressource (requête POST), vous devez transférer cette ressource. Il en va de même pour la modification d'une ressource existante. En REST, les formats XML ou JSON sont le plus souvent utilisés pour transmettre le corps de la requête. Le format le plus courant est JSON. Supposons que nous voulions envoyer une requête au serveur et y créer une nouvelle ressource. Si vous vous en souvenez, à titre d'exemple, nous avons examiné 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 suivantes sur les clients : Nom Email Numéro de téléphone Le corps d'une telle demande pourrait alors être le JSON suivant :

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

Regrouper les demandes

Nous avons donc regardé en quoi peut consister une demande client. Donnons maintenant quelques exemples de requêtes avec des descriptions

Réponses

Disons quelques mots sur les réponses du serveur. La réponse se compose généralement des éléments suivants :

• 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 dans les requêtes. Je pense que tout est clair également dans le corps de la réponse. L'organisme renvoie souvent les informations demandées par le client. Les informations peuvent être renvoyées dans le même format JSON pour les requêtes GET. Mais la dernière partie est un peu plus intéressante.

Codes de réponse HTTP

Examinons de plus près les codes de réponse HTTP. Voici une citation de Wikipédia : Le code d'état HTTP fait partie de la première ligne de la réponse du serveur aux requêtes via le protocole HTTP. C'est un entier à trois chiffres décimaux. Le premier chiffre indique la classe de la condition. Le code de réponse est généralement suivi d'une phrase explicative en anglais séparée par un espace, qui explique à la personne la raison de cette réponse particulière. Exemples:

• 201 Créé ;
• 401 Non autorisé ;
• 507 Stockage insuffisant.

Le client apprend du code de réponse les résultats de sa demande et détermine les actions à entreprendre ensuite. Les codes de réponse sont divisés en plusieurs groupes :

• 1ХХ - informatif ;
• 2ХХ - informer sur les cas d'acceptation et de traitement réussis de la demande d'un client ;
• 3XX - informe le client que pour mener à bien l'opération, il est nécessaire de faire une autre requête, généralement en utilisant un URI différent ;
• 4ХХ - erreur client. Par exemple, une requête mal construite ou le code bien connu 404 Not Found, qui peut se produire lorsqu'un client demande une ressource inexistante ;
• 5ХХ - erreur de serveur. Renvoyé au client si l'opération échoue en raison d'une faute du serveur.

Vous pouvez en savoir plus sur tous les codes ici . Partie 1 : Qu'est-ce que REST Partie 3 : Création d'un service RESTful dans Spring Boot