QU’est-ce que REST?

transfert D’État de représentation

REST, ou transfert D’État de représentation, est un style architectural pour fournir des normes entre les systèmes informatiques sur le web, ce qui facilite la communication entre les systèmes. Les systèmes compatibles REST, souvent appelés systèmes RESTful, sont caractérisés par leur absence d’état et séparent les préoccupations du client et du serveur. Nous allons entrer dans ce que ces termes signifient et pourquoi ils sont des caractéristiques bénéfiques pour les services sur le Web.,

séparation du Client et du serveur

dans le style architectural REST, l’implémentation du client et l’implémentation du serveur peuvent se faire indépendamment sans connaître l’un de l’autre. Cela signifie que le code côté client peut être modifié à tout moment sans affecter le fonctionnement du serveur, et le code sur le côté serveur peut être modifié sans affecter le fonctionnement du client.

tant que chaque côté sait quel format de messages Envoyer à l’autre, ils peuvent être conservés modulaires et séparés., En séparant les problèmes d’interface utilisateur des problèmes de stockage de données, nous améliorons la flexibilité de l’interface sur toutes les plateformes et améliorons l’évolutivité en simplifiant les composants du serveur. De plus, la séparation permet à chaque composant d’évoluer indépendamment.

en utilisant une interface REST, différents clients atteignent les mêmes points de terminaison REST, effectuent les mêmes actions et reçoivent les mêmes réponses.,

apatridie

Les systèmes qui suivent le paradigme REST sont sans état, ce qui signifie que le serveur n’a pas besoin de savoir dans quel état se trouve le client et vice versa. De cette façon, le serveur et le client peuvent comprendre n’importe quel message reçu, même sans voir les messages précédents. Cette contrainte d’apatridie est imposée par l’utilisation de ressources plutôt que de commandes. Les ressources sont les noms du Web – elles décrivent tout objet, document ou chose que vous pourriez avoir besoin de stocker ou d’Envoyer à d’autres services.,

étant donné que les systèmes REST interagissent via des opérations standard sur les ressources, ils ne dépendent pas de l’implémentation d’interfaces.

Ces contraintes aident les applications RESTful à atteindre la fiabilité, les performances rapides et l’évolutivité, en tant que composants pouvant être gérés, mis à jour et réutilisés sans affecter le système dans son ensemble, même pendant le fonctionnement du système.

maintenant, nous allons explorer comment la communication entre le client et le serveur se produit réellement lorsque nous implémentons une interface RESTful.,

Communication entre le client et le serveur

dans L’architecture REST, les clients envoient des requêtes pour récupérer ou modifier des ressources, et les serveurs envoient des réponses à ces requêtes. Jetons un coup d’œil aux moyens standard de faire des demandes et d’envoyer des réponses.

faire des requêtes

REST nécessite qu’un client fasse une requête au serveur afin de récupérer ou de modifier des données sur le serveur.,lient pour transmettre des informations sur la requête

Un chemin d’accès à une ressource

Un corps de message Facultatif contenant des données

verbes HTTP

il existe 4 verbes HTTP de base que nous utilisons dans les requêtes pour interagir avec des ressources dans un système REST:

• GET — récupérer une ressource spécifique ressource spécifique (par ID)
• supprimer — supprimer une ressource spécifique par ID

Vous pouvez en savoir plus sur ces verbes HTTP dans l’article suivant de Codecademy:

• qu’est — ce que Crud?,

en-têtes et paramètres D’acceptation

dans l’en-tête de la requête, le client envoie le type de contenu qu’il peut recevoir du serveur. C’est ce qu’on appelle le champ Accept, Et il garantit que le serveur n’envoie pas de données qui ne peuvent pas être comprises ou traitées par le client. Les options pour les types de contenu sont les Types MIME (ou Multipurpose Internet Mail Extensions, dont vous pouvez en savoir plus dans les documents Web MDN.,

les Types MIME, utilisé pour spécifier les types de contenu dans la balise Accept le terrain, composée d’un type et un subtype. Ils sont séparés par une barre oblique (/).

Par exemple, un fichier texte contenant du HTML serait spécifié avec le type text/html. Si ce fichier texte contenait CSS à la place, il serait spécifié comme text/css. Un fichier texte générique serait noté text/plain. Cette valeur par défaut, text/plain, n’est cependant pas un fourre-tout., Si un client attend text/css et reçoit text/plain, il ne sera pas en mesure de reconnaître le contenu.

d’Autres types et couramment utilisés types:

Par exemple, un client qui accède à une ressource avec des id le 23 dans un articles ressource sur un serveur peut envoyer une requête comme ceci:

Le Accept champ d’en-tête dans ce cas, on dit que le client accepte le contenu dans text/html ou application/xhtml.,

les Chemins

les Requêtes doivent contenir un chemin d’accès à une ressource que l’opération doit être exécutée. Dans les API RESTful, les chemins doivent être conçus pour aider le client à savoir ce qui se passe.

classiquement, la première partie du chemin doit être la forme plurielle de la ressource. Cela permet de garder les chemins imbriqués simples à lire et faciles à comprendre.

Un chemin comme fashionboutique.com/customers/223/orders/12 est clair dans ce qu’il désigne, même si vous n’avez jamais vu cette voie avant, parce qu’il est hiérarchique et descriptif., Nous pouvons voir que nous accédons à la commande avec id12 pour le client avec id

Les chemins doivent contenir les informations nécessaires pour localiser une ressource avec le degré de spécificité nécessaire. Lorsque vous faites référence à une liste ou à une collection de ressources, il n’est pas toujours nécessaire d’ajouter un id. Par exemple, une requête POST au chemin fashionboutique.com/customers n’aurait pas besoin d’un identifiant supplémentaire, car le serveur générera un id pour le nouvel objet.,

Si nous essayons d’accéder à une seule ressource, nous devrions ajouter unid au chemin.Par exemple:GET fashionboutique.com/customers/:id — récupère l’élément dans le customers ressources id spécifié.DELETE fashionboutique.com/customers/:id — supprime l’élément dans le customers ressources id spécifié.,

envoi de réponses

types de contenu

dans les cas où le serveur envoie une charge utile de données au client, le serveur doit inclure uncontent-type dans l’en-tête de la réponse. Ce champ d’en-têtecontent-type alerte le client sur le type de données qu’il envoie dans le corps de la réponse. Ces types de contenu sont des Types MIME, tout comme ils le sont dans le champ accept de l’en-tête de la requête., Le content-type que le serveur renvoie dans la réponse doit être l’une des options spécifiées par le client dans le champ accept de la requête.,

Par exemple, lorsqu’un client accède à une ressource avec des id le 23 dans un articles ressource avec cette Requête GET:

Le serveur peut envoyer du contenu avec l’en-tête de réponse:

Cela signifie que le contenu demandé est de retour dans le corps de la réponse avec un content-type de text/html, ce que le client dit qu’il serait en mesure d’accepter.,

codes de réponse

Les réponses du serveur contiennent des codes d’État pour alerter le client des informations sur le succès de l’opération. En tant que développeur, vous n’avez pas besoin de connaître tous les code d’état (il y en a beaucoup), mais il faut savoir les plus courantes et comment ils sont utilisés:

pour chaque verbe HTTP, il y a des codes d’état attendus qu’un serveur doit retourner en cas de succès:

• GET — return 200 (OK)
• POST — return 201 (CREATED)
• PUT — return 200 (CREATED)
• PUT — return 200 (OK)
• delete-return 204 (No Content) si l’opération échoue, renvoie le code d’état le plus spécifique possible correspondant au problème rencontré.,

exemples de demandes et de réponses

disons que nous avons une application qui vous permet de visualiser, créer, modifier et supprimer des clients et des commandes pour un petit magasin de vêtements hébergé àfashionboutique.com. Nous pourrions créer une API HTTP qui permet à un client d’effectuer ces fonctions:

Si nous voulions afficher tous les clients, la demande ressemblerait à ceci:

un en-tête de réponse possible ressemblerait à:

suivi du customers données demandées au format application/json.,

Créer un nouveau client par l’affichage de données:

ensuite, Le serveur génère un id pour que l’objet et le renvoie au client, avec un en-tête comme:

Pour afficher un seul client, nous nous mettons en précisant que client id:

Une réponse possible de l’en-tête ressemblerait à:

suivi par les données de la balise customer ressource id 23 application/json format.,

nous pouvons mettre à jour ce client en mettant les nouvelles données:

un en-tête de réponse possible auraitStatus Code: 200 (OK), pour informer le client que l’élément avecid 123 a été modifié.

On peut aussi SUPPRIMER le client en spécifiant son id:

La réponse aurait un en-tête contenant Status Code: 204 (NO CONTENT), en en informant le client que l’élément avec des id 123 a été supprimé, et rien dans le corps.,

pratique avec REST

imaginons que nous construisons un site de collection de photos. Nous voulons créer une API pour garder une trace des utilisateurs, des sites et des photos de ces sites. Ce site a une index.html et un style.css. Chaque utilisateur a un nom d’utilisateur et un mot de passe. Chaque photo a un lieu et un propriétaire (c’est à dire l’utilisateur qui a pris la photo). Chaque lieu a un nom et une adresse.,d= »229c60b6ce »>

Request-POST /venuesResponse-201 (CREATED)Content-type: application/json

Request-POST /venues/:id/photosResponse-201 (CREATED)Content-type: application/json

PUT Requests

Request-PUT /users/:idResponse-200 (OK)

Request-PUT /venues/:idResponse-200 (OK)

Request-PUT /venues/:id/photos/:idResponse-200 (OK)

DELETE Requests

Request-DELETE /venues/:idResponse-204 (NO CONTENT)

Request-DELETE /venues/:id/photos/:idResponse-204 (NO CONTENT)