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 :
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 :
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
Demande
Description
GET /customers/23
Accept : application/json, application/xml
Obtenir des informations sur le client n°23 au format JSON ou XML
Modifiez le client n° 1 comme suit :
Nom — Ben
E-mail — bigben@jr.com
Numéro de téléphone — +86 (868) 686-8686
DELETE /customers/12/orders/6
Supprimer la commande n° 6 effectuée par le client n° 12 du système
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
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 :
