8.1 Approche API distante
Tous les programmeurs font la même erreur lors de la construction d'une architecture client-serveur. Ils commencent à traiter les demandes adressées au serveur comme des appels de méthode .
Vous souhaitez démarrer le processus de génération de rapport sur le serveur, pourquoi ne pas lui envoyer une requête du type :
http://server.com/startDocumentGeneration?paramsEt comment télécharger le rapport une fois terminé ? Pour ce faire, nous allons écrire une autre méthode :
http://server.com/getDocumentLe serveur HttpSessionstocke des informations sur notre document, et dès que le document est généré, le serveur le restitue.
Excellente approche. Ou non?
L'approche est vraiment terrible. Le fait est que le serveur doit se souvenir du numéro de document. En d'autres termes, afin de traiter correctement les nouveaux appels de méthode, le serveur doit mémoriser les résultats de l'appel des méthodes précédentes.
Sur le web, c'est un gros problème. Internet peut disparaître, le navigateur peut se fermer. La page peut être rechargée ou accidentellement cliqué sur un lien, et ainsi de suite. Et le serveur continuera à stocker des mégaoctets de données provenant de demandes d'utilisateurs précédentes ...
Pour un travail confortable avec le serveur, vous ne pouvez pas vous attendre à toujours avoir à portée de main les données des demandes précédentes adressées au serveur.
Comment alors appeler les méthodes du serveur ? La bonne réponse serait terrible : pas question !
8.2 Approche REST
Les programmeurs sont revenus à l'essentiel et se sont souvenus qu'initialement la requête contenait le chemin d'accès au fichier sur le serveur :
http://server.com/path?paramsEt nous avons décidé d'utiliser cette approche au maximum.
Désormais, le serveur est considéré comme un référentiel de données visible de l'extérieur sous la forme d'une arborescence .
Si vous souhaitez obtenir une liste de tous les utilisateurs, appelez la requête :
http://server.com/usersSi vous souhaitez obtenir des données sur l'utilisateur 113, exécutez la requête :
http://server.com/users/113Et ainsi de suite, le tout dans le même esprit.
Encore une fois, le serveur est vu comme un référentiel de données visible de l'extérieur sous la forme d'une arborescence.
Les données peuvent être reçues - requêtes GET , modifiées - requête POST et supprimées - requête DELETE .
8.3 Pas d'état
Le protocole REST d'interaction entre le client et le serveur requiert la condition suivante : pendant la période entre les requêtes du client, aucune information sur l'état du client n'est stockée sur le serveur.
Toutes les demandes du client doivent être conçues de manière à ce que le serveur reçoive à chaque fois toutes les informations dont il a besoin pour répondre à la demande . L'état de la session est enregistré côté client.
Lors du traitement des demandes du client, le client est considéré comme étant dans un état transitoire. Chaque état d'application individuel est représenté par des liens qui peuvent être invoqués la prochaine fois que le client se connecte.
8.4 Uniformité de l'interface
Tous les chemins utilisés pour récupérer les objets du serveur sont standardisés. C'est très pratique, surtout si vous obtenez des données d'autres serveurs REST.
Toutes les interfaces d'objet doivent respecter trois conditions :
Identification des ressources
Toutes les ressources sont identifiées dans les requêtes à l'aide d'un URI. Les ressources à l'intérieur du serveur sont distinctes des vues qui sont renvoyées aux clients. Par exemple, un serveur peut envoyer des données à partir d'une base de données au format HTML, XML ou JSON, dont aucun n'est un type de stockage au sein du serveur.
Manipulation des ressources via une vue
Si le client stocke une représentation de la ressource, y compris les métadonnées, il dispose alors de suffisamment d'informations pour modifier ou supprimer la ressource sur le serveur.
Messages "auto-descriptifs"
Chaque message contient suffisamment d'informations pour comprendre comment le traiter. Par exemple, si vous avez besoin d'informations sur l'utilisateur, le serveur vous renverra un objet JSON, où il y aura des champs de nom et d'adresse.
Il ne devrait pas y avoir de situation où le client doit savoir que le premier chiffre de la réponse est l'âge et le second la date de naissance.
8.5 Mise en cache
L'approche REST suppose que les demandes de données sont effectuées via le protocole HTTP. Par conséquent, les objets sont obtenus en appelant une requête GET. Cela signifie qu'elles sont, comme toutes les ressources reçues via une requête GET, soumises à toutes les règles de mise en cache des ressources HTTP.
Autrement dit, les données reçues via l'API REST sont mises en cache de la même manière que toutes les ressources statiques sur les serveurs Web. Beauté :)