Services Web RESTful - Apatridie

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.

Les services Web RESTful doivent respecter cette restriction. Nous avons vu cela dans le chapitre Services Web RESTful - Méthodes , que les méthodes du service Web ne stockent aucune information du client à partir duquel elles sont appelées.

Consider the following URL −

https: // localhost: 8080 / UserManagement / rest / UserService / users / 1

Si vous appuyez sur l'url ci-dessus en utilisant votre navigateur ou en utilisant un client Java ou en utilisant Postman, le résultat sera toujours le XML utilisateur dont l'ID est 1 car le serveur ne stocke aucune information sur le client.

<user> 
   <id>1</id> 
   <name>mahesh</name> 
   <profession>1</profession> 
</user>

Avantages de l'apatridie

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 de l'application.

  • Comme HTTP est lui-même un protocole sans état, les services Web RESTful fonctionnent de manière transparente avec les protocoles HTTP.

Inconvénients de l'apatridie

Voici les inconvénients 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.