REST signifie REpresentational State Transfer.
REST est une architecture basée sur des normes Web et utilise le protocole HTTP pour la communication de données. Il tourne autour de la ressource où chaque composant est une ressource et une ressource est accessible par une interface commune à l'aide de méthodes standard HTTP. REST a été introduit pour la première fois par Roy Fielding en 2000.
Dans l'architecture REST, un serveur REST fournit simplement l'accès aux ressources et aux accès client REST et présente les ressources. Ici, chaque ressource est identifiée par des URI / ID globaux. REST utilise diverses représentations pour représenter une ressource comme du texte, JSON et XML. Aujourd'hui, JSON est le format le plus utilisé dans les services Web.
Les méthodes HTTP bien connues suivantes sont couramment utilisées dans l'architecture basée sur REST -
GET - Fournit un accès en lecture seule à une ressource.
PUT - Utilisé pour mettre à jour une ressource existante ou créer une nouvelle ressource.
DELETE - Utilisé pour supprimer une ressource.
POST - Utilisé pour créer une nouvelle ressource.
OPTIONS - Utilisé pour obtenir les opérations prises en charge sur une ressource.
Un service Web est un ensemble de protocoles et de normes ouverts utilisés pour l'échange de données entre des applications ou des systèmes. Les applications logicielles écrites dans divers langages de programmation et exécutées sur diverses plates-formes peuvent utiliser des services Web pour échanger des données sur des réseaux informatiques comme Internet d'une manière similaire à la communication inter-processus sur un seul ordinateur.
Les services Web basés sur l'architecture REST sont appelés services Web RESTful. Ces services Web utilisent des méthodes HTTP pour implémenter le concept d'architecture REST. Un service Web RESTful définit généralement un URI, Uniform Resource Identifier un service, fournit une représentation des ressources telle que JSON et un ensemble de méthodes HTTP.
L'architecture REST traite chaque contenu comme une ressource. Ces ressources peuvent être des fichiers texte, des pages html, des images, des vidéos ou des données d'entreprise dynamiques. Le serveur REST fournit simplement l'accès aux ressources et le client REST accède et modifie les ressources. Ici, chaque ressource est identifiée par des URI / ID globaux.
REST utilise diverses représentations pour représenter une ressource où texte, JSON, XML. XML et JSON sont les représentations les plus populaires des ressources.
Voici les points importants à prendre en compte lors de la conception d'un format de représentation d'une ressource dans un service Web RESTful -
Understandability - Le serveur et le client doivent être capables de comprendre et d'utiliser le format de représentation de la ressource.
Completeness- Le format doit pouvoir représenter une ressource complètement. Par exemple, une ressource peut contenir une autre ressource. Le format doit pouvoir représenter des structures de ressources aussi bien simples que complexes.
Linkablity - Une ressource peut avoir un lien avec une autre ressource, un format doit être capable de gérer de telles situations.
Les services Web RESTful utilisent le protocole HTTP comme moyen de communication entre le client et le serveur.
Un client envoie un message sous la forme d'une requête HTTP et le serveur répond sous la forme d'une réponse HTTP. Cette technique est appelée Messagerie. Ces messages contiennent des données de message et des métadonnées, c'est-à-dire des informations sur le message lui-même.
Une requête HTTP comprend cinq parties principales -
Verb - Indiquez les méthodes HTTP telles que GET, POST, DELETE, PUT, etc.
URI - Uniform Resource Identifier (URI) pour identifier la ressource sur le serveur.
HTTP Version - Indiquez la version HTTP, par exemple HTTP v1.1.
Request Header- Contient des métadonnées pour le message HTTP Request sous forme de paires clé-valeur. Par exemple, type de client (ou navigateur), format pris en charge par le client, format du corps du message, paramètres de cache, etc.
Request Body - Contenu du message ou représentation des ressources.
Une réponse HTTP comprend quatre parties principales -
Status/Response Code- Indiquez l'état du serveur pour la ressource demandée. Par exemple, 404 signifie que la ressource est introuvable et 200 signifie que la réponse est correcte.
HTTP Version - Indiquez la version HTTP, par exemple HTTP v1.1.
Response Header- Contient des métadonnées pour le message de réponse HTTP sous forme de paires clé-valeur. Par exemple, la longueur du contenu, le type de contenu, la date de réponse, le type de serveur, etc.
Response Body - Contenu du message de réponse ou représentation des ressources.
L'adressage fait référence à la localisation d'une ressource ou de plusieurs ressources se trouvant sur le serveur. Il est analogue de localiser l'adresse postale d'une personne.
URI signifie Uniform Resource Identifier. Chaque ressource de l'architecture REST est identifiée par son URI.
Le but d'un URI est de localiser une ou plusieurs ressources sur le serveur hébergeant le service Web.
Un URI est du format suivant -
<protocol>://<service-name>/<ResourceType>/<ResourceID>VERB identifie l'opération à effectuer sur la ressource.
Voici les points importants à prendre en compte lors de la conception d'un URI -
Use Plural Noun- Utilisez un nom pluriel pour définir les ressources. Par exemple, nous avons utilisé des utilisateurs pour identifier les utilisateurs en tant que ressource.
Avoid using spaces - Utilisez un trait de soulignement (_) ou un trait d'union (-) lorsque vous utilisez un nom de ressource long, par exemple, utilisez allowed_users au lieu de% 20users autorisés.
Use lowercase letters - Bien que l'URI ne soit pas sensible à la casse, il est recommandé de ne conserver l'URL qu'en minuscules.
Maintain Backward Compatibility- Le service Web étant un service public, un URI une fois rendu public devrait toujours être disponible. Au cas où l'URI serait mis à jour, redirigez l'ancien URI vers le nouvel URI en utilisant le code d'état HTTP, 300.
Use HTTP Verb- Utilisez toujours le verbe HTTP comme GET, PUT et DELETE pour effectuer les opérations sur la ressource. Il n'est pas bon d'utiliser les noms d'opérations dans l'URI.
Selon l'architecture REST, un service Web RESTful ne doit pas conserver un état client sur le serveur. Cette restriction s'appelle l'apatridie. Il est de la responsabilité du client de transmettre son contexte au serveur, puis le serveur peut stocker ce contexte pour traiter la demande ultérieure du client. Par exemple, la session maintenue par le serveur est identifiée par l'identifiant de session transmis par le client.
Voici les avantages de l'apatridie dans les services Web RESTful -
Les services Web peuvent traiter chaque demande de méthode indépendamment.
Les services Web n'ont pas besoin de conserver les interactions précédentes du client. Cela simplifie la conception des applications.
Comme HTTP est lui-même un protocole sans état, les services Web RESTful fonctionnent de manière transparente avec le protocole HTTP.
Voici l'inconvénient de l'apatridie dans les services Web RESTful -
Les services Web doivent obtenir des informations supplémentaires dans chaque requête, puis interpréter pour obtenir l'état du client au cas où les interactions avec le client seraient prises en charge.
Les opérations idempotentes signifient que leur résultat sera toujours le même quel que soit le nombre de fois que ces opérations sont appelées.
Les opérations PUT et DELETE sont idempotentes.
Les opérations GET sont en lecture seule et sont sûres.
Les opérations PUT et POST sont presque identiques, la différence se situant uniquement dans le résultat où l'opération PUT est idempotente et l'opération POST peut entraîner un résultat différent.
Il doit répertorier les opérations prises en charge dans un service Web et doit être en lecture seule.
Il ne doit renvoyer que l'en-tête HTTP, aucun corps et doit être en lecture seule.
La mise en cache fait référence au stockage de la réponse du serveur dans le client lui-même afin qu'un client n'ait pas besoin de demander au serveur la même ressource encore et encore. Une réponse de serveur doit contenir des informations sur la manière dont une mise en cache doit être effectuée afin qu'un client mette en cache la réponse pendant un certain temps ou ne mette jamais en cache la réponse du serveur.
L'en-tête Date fournit la date et l'heure de la ressource lors de sa création.
L'en-tête Last Modified fournit la date et l'heure de la dernière modification de la ressource.
Cache-Control est l'en-tête principal pour contrôler la mise en cache.
L'en-tête Expires définit la date et l'heure d'expiration de la mise en cache.
La directive publique indique que la ressource peut être mise en cache par n'importe quel composant.
La directive privée indique que la ressource peut être mise en cache uniquement par le client et le serveur, aucun intermédiaire ne peut mettre en cache la ressource.
La directive no-cache / no-store indique que la ressource n'est pas cachable.
La directive max-age indique que la mise en cache est valide jusqu'à max-age en secondes. Après cela, le client doit faire une autre demande.
La directive must-revalidate indique au serveur de revalider la ressource si max-age est passé.
Gardez toujours les contenus statiques comme les images, css, JavaScript mis en cache, avec une date d'expiration de 2 à 3 jours. Ne gardez jamais la date d'expiration trop élevée.
Le contenu dynamique ne doit être mis en cache que pendant quelques heures.Comme les services Web RESTful fonctionnent avec les chemins d'URL HTTP, il est donc très important de protéger un service Web RESTful de la même manière qu'un site Web est sécurisé. Voici les meilleures pratiques à suivre lors de la conception d'un service Web RESTful -
Validation- Validez toutes les entrées sur le serveur. Protégez votre serveur contre les attaques par injection SQL ou NoSQL.
Session based authentication - Utilisez l'authentification basée sur la session pour authentifier un utilisateur chaque fois qu'une demande est faite à une méthode de service Web.
No sensitive data in URL - N'utilisez jamais de nom d'utilisateur, de mot de passe ou de jeton de session dans l'URL, ces valeurs doivent être transmises au service Web via la méthode POST.
Restriction on Method execution- Autoriser l'utilisation restreinte de méthodes telles que GET, POST, DELETE. La méthode GET ne doit pas être en mesure de supprimer des données.
Validate Malformed XML/JSON - Vérifiez les entrées correctement formées transmises à une méthode de service Web.
Throw generic Error Messages - Une méthode de service Web doit utiliser des messages d'erreur HTTP comme 403 pour afficher l'accès interdit, etc.
Les codes d'état HTTP sont des codes standard et font référence à l'état prédéfini de la tâche effectuée sur le serveur. Par exemple, l'état HTTP 404 indique que la ressource demandée n'est pas présente sur le serveur.
Cela signifie, OK, montre le succès.
Cela signifie, CRÉÉ, lorsqu'une ressource est créée avec succès à l'aide d'une requête POST ou PUT. Renvoyer le lien vers la ressource nouvellement créée à l'aide de l'en-tête d'emplacement.
Cela signifie, PAS DE CONTENU, lorsque le corps de la réponse est vide, par exemple, une requête DELETE.
Cela signifie, NON MODIFIÉ, utilisé pour réduire l'utilisation de la bande passante du réseau en cas de requêtes GET conditionnelles. Le corps de la réponse doit être vide. Les en-têtes doivent avoir la date, l'emplacement, etc.
Cela signifie, BAD REQUEST, indique qu'une entrée invalide est fournie, par exemple une erreur de validation, des données manquantes.
Cela signifie, INTERDIT, indique que l'utilisateur n'a pas accès à la méthode utilisée, par exemple, supprimer l'accès sans droits d'administrateur.
Cela signifie, NON TROUVÉ, indique que la méthode n'est pas disponible.
Cela signifie, CONFLIT, indique une situation de conflit lors de l'exécution de la méthode, par exemple, en ajoutant une entrée en double.
Cela signifie, ERREUR SERVEUR INTERNE, indique que le serveur a levé une exception lors de l'exécution de la méthode.
JAX-RS signifie JAVA API for RESTful Web Services. JAX-RS est une API de langage de programmation basée sur JAVA et une spécification permettant de prendre en charge les services Web RESTful créés. Sa version 2.0 est sortie le 24 mai 2013. JAX-RS fait un usage intensif des annotations disponibles à partir de Java SE 5 pour simplifier le développement de la création et du déploiement de services Web basés sur JAVA. Il fournit également des supports pour la création de clients pour les services Web RESTful.