La réponse courte et directe
Puisque la demande parle d'exécuter la liste des tâches (les tâches sont la ressource dont nous parlons ici), si le groupe de tâches a été déplacé vers l'exécution (c'est-à-dire quel que soit le résultat de l'exécution), il serait judicieux que le statut de la réponse sera 200 OK
. Sinon, si un problème empêchait l'exécution du groupe de tâches, tel qu'un échec de la validation des objets de tâche , ou qu'un service requis n'était pas disponible, le statut de la réponse devrait indiquer cette erreur. Après cela, lorsque l'exécution des tâches commence, étant donné que les tâches à exécuter sont répertoriées dans le corps de la demande, je m'attendrais alors à ce que les résultats de l'exécution soient répertoriés dans le corps de la réponse.
La longue réponse philosophique
Vous rencontrez ce dilemme parce que vous vous détournez de ce pour quoi HTTP a été conçu. Vous ne l’interagissez pas pour gérer les ressources, vous l’utilisez plutôt comme moyen d’invocation de méthode à distance (ce qui n’est pas très étrange, mais fonctionne mal sans un schéma préconçu).
Compte tenu de ce qui précède et sans avoir le courage de transformer cette réponse en un long guide d’opinion, voici un schéma d’URI conforme à une approche de gestion des ressources:
/tasks
GET
liste toutes les tâches, paginées
POST
ajoute une seule tâche
/tasks/task/[id]
GET
répond avec l'objet d'état d'une seule tâche
DELETE
annule / supprime une tâche
/tasks/groups
GET
liste tous les groupes de tâches, paginés
POST
ajoute un groupe de tâches
/tasks/groups/group/[id]
GET
répond avec l'état d'un groupe de tâches
DELETE
annule / supprime le groupe de tâches
Cette structure parle de ressources, pas de quoi en faire. Ce qui se fait avec les ressources concerne un autre service.
Un autre point important à souligner est qu’il est conseillé de ne pas bloquer trop longtemps dans un gestionnaire de requêtes HTTP. Tout comme l'interface utilisateur, une interface HTTP doit être réactive - dans une échelle de temps inférieure de quelques ordres de grandeur (car cette couche traite des entrées / sorties).
Passer à la conception d'une interface HTTP qui gère strictement les ressources est probablement aussi difficile que de déplacer le travail d'un thread d'interface utilisateur lorsqu'un bouton est cliqué. Cela nécessite que le serveur HTTP communique avec d'autres services pour exécuter des tâches plutôt que de les exécuter dans le gestionnaire de demandes. Ce n'est pas une implémentation superficielle, c'est un changement de direction.
Quelques exemples d'utilisation d'un tel schéma d'URI
Exécuter une tâche unique et suivre les progrès:
POST /tasks
avec la tâche à exécuter
GET /tasks/task/[id]
jusqu'à ce que l'objet de réponse completed
ait une valeur positive tout en affichant l'état actuel / l'avancement
Exécution d'une tâche unique et en attente de son achèvement:
POST /tasks
avec la tâche à exécuter
GET /tasks/task/[id]?awaitCompletion=true
Until completed
a une valeur positive (probablement un délai d'expiration, c'est pourquoi il devrait être mis en boucle)
Exécution d'un groupe de tâches et suivi des progrès:
POST /tasks/groups
avec le groupe de tâches à exécuter
GET /tasks/groups/group/[groupId]
jusqu'à ce que la completed
propriété d' objet de réponse ait une valeur, indiquant le statut de la tâche individuelle (3 tâches terminées sur 5, par exemple)
Demander une exécution pour un groupe de tâches et attendre son achèvement:
POST /tasks/groups
avec le groupe de tâches à exécuter
GET /tasks/groups/group/[groupId]?awaitCompletion=true
jusqu'à ce que répond avec un résultat qui indique l'achèvement (probablement a un délai d'attente, c'est pourquoi devrait être mis en boucle)