REST en pratique : Comment implémenter des services asynchrones ?
Le protocole HTTP est un protocole synchrone et sans état. lorsqu’un client soumet une requête au serveur, le client s’attend a une réponse, que ce soit un succès ou une erreur. Ceci ne veut pas forcement dire que le serveur doit finir de traiter la requête avant d’envoyer la réponse. Par exemple, un service qui effectue des traitements d’image (conversion, reconnaissance faciale etc.) peut prendre des secondes ou des heures a faire le traitement dépendamment de la taille les images uploadées a ce service. Comment traiter donc ces cas de requête qui prennent du temps en REST?
Pour ce faire, le client appelle le serveur en effectuant une requête POST. À la réception de la requête, le serveur crée une nouvelle ressource et retourne un code “202 Accepted” avec une représentation de cette nouvelle ressource. L’objectif de cette ressource est de permettre au client de suivre l’état de la tache asynchrone. Cette ressource doit être conçue de telle sorte que sa représentation inclut l’état courant de la requête et de l’information reliée comme un estimé de temps.
Le client crée la ressource task et reçoit l’identifiant du serveur
Par la suite, le client peut suivre l’état de la tache en effectuant des requêtes GET à la ressource. Dépendamment de l’état courant de la ressource, retournez l’un des codes suivants :
- tâche en traitement : retourner un code “200 OK” et une représentation de la tache ressource avec l’état courant. Cet état inclut aussi une information sur la prochaine date a laquelle il devrait récupérer l’état.
Le client appelle la ressource et reçoit un 200 OK
- tâche terminée correctement : retourner un code “303 See Other” et une entête “Location” contenant l’URI de la ressource qui représente le résultat de la tache.
Le client reçoit un 303 See Other ainsi que le lien vers la ressource résultante de la tâche
- tâche en erreur : retourner un code “200 OK” avec une représentation de la tache ressource et de l’information sur l’erreur survenue. Les clients doivent lire le corps de la réponse pour récupérer la cause de l’erreur.
