La respuesta corta y directa
Dado que la solicitud habla de ejecutar la lista de tareas (las tareas son el recurso del que estamos hablando aquí), entonces si el grupo de tareas se ha adelantado a la ejecución (es decir, independientemente del resultado de la ejecución), entonces sería sensato que el estado de respuesta sea 200 OK
. De lo contrario, si hubiera un problema que impidiera la ejecución del grupo de tareas, como el error de validación de los objetos de tarea , o algún servicio requerido no esté disponible, por ejemplo, el estado de la respuesta debe indicar que error. Más allá de eso, cuando comience la ejecución de las tareas, ya que las tareas a realizar se enumeran en el cuerpo de la solicitud, entonces espero que los resultados de la ejecución se enumeren en el cuerpo de la respuesta.
La respuesta larga y filosófica
Estás experimentando este dilema porque estás desviando de lo que HTTP fue diseñado. No lo está interactuando para administrar recursos, sino que lo está utilizando como medio de invocación de métodos remotos (lo cual no es muy extraño, sin embargo, funciona mal sin un esquema preconcebido).
Habiendo dicho lo anterior, y sin valor para convertir esta respuesta en una guía de opinión larga, el siguiente es un esquema de URI que se ajusta a un enfoque de gestión de recursos:
-
%código%
-
/tasks
enumera todas las tareas, paginadas
-
GET
agrega una sola tarea
-
%código%
-
POST
responde con el objeto de estado de una sola tarea
-
/tasks/task/[id]
cancela / elimina una tarea
-
%código%
-
GET
enumera todos los grupos de tareas, paginados
-
DELETE
agrega un grupo de tareas
-
%código%
-
/tasks/groups
responde con el estado de un grupo de tareas
-
GET
cancela / elimina el grupo de tareas
Esta estructura habla de recursos, no de qué hacer con ellos. Lo que se está haciendo con los recursos es la preocupación de otro servicio.
Otro punto importante que se debe hacer es que es recomendable no bloquear durante mucho tiempo en un controlador de solicitudes HTTP. Al igual que la interfaz de usuario, una interfaz HTTP debe ser receptiva, en una escala de tiempo que es algunos órdenes de magnitud más lenta (porque esta capa se ocupa de IO).
Es probable que avanzar hacia el diseño de una interfaz HTTP que gestione estrictamente los recursos sea tan difícil como alejar el trabajo de un hilo de la interfaz de usuario cuando se hace clic en un botón. Requiere que el servidor HTTP se comunique con otros servicios para ejecutar tareas en lugar de ejecutarlas en el controlador de solicitudes. Esto no es una implementación superficial, es un cambio de dirección.
Algunos ejemplos de cómo se usaría tal esquema de URI
Ejecución de una sola tarea y seguimiento del progreso:
-
POST
con la tarea a ejecutar
-
/tasks/groups/group/[id]
hasta que el objeto de respuesta GET
tenga un valor positivo al tiempo que muestra el estado / progreso actual
Ejecutando una sola tarea y esperando su finalización:
-
DELETE
con la tarea a ejecutar
-
POST /tasks
hasta que GET /tasks/task/[id]
tenga un valor positivo (es probable que tenga un tiempo de espera, por lo que este debe ser un bucle)
Ejecución de un grupo de tareas y seguimiento del progreso:
-
completed
con el grupo de tareas a ejecutar
-
POST /tasks
hasta que la propiedad de objeto de respuesta GET /tasks/task/[id]?awaitCompletion=true
tenga valor, mostrando el estado de la tarea individual (3 tareas completadas de 5, por ejemplo)
Solicitando una ejecución para un grupo de tareas y esperando su finalización:
-
completed
con el grupo de tareas a ejecutar
-
POST /tasks/groups
hasta que responda con un resultado que denota la finalización (es probable que tenga un tiempo de espera, por lo que debería estar en un bucle)