A resposta curta e direta
Como o pedido fala de executar a lista de tarefas (tarefas são o recurso do qual estamos falando aqui), então se o grupo de tarefas foi movido para a execução (isto é, independentemente do resultado da execução), então seria sensato que o status da resposta fosse 200 OK
. Caso contrário, se houver um problema que impeça a execução do grupo de tarefas, como a falha na validação dos objetos da tarefa , ou algum serviço necessário não estiver disponível, por exemplo, o status da resposta deve denotar erro. Passado isso, quando a execução das tarefas começa, visto que as tarefas a serem executadas estão listadas no corpo da solicitação, então eu esperaria que os resultados da execução fossem listados no corpo da resposta.
A longa resposta filosófica
Você está passando por esse dilema porque está se desviando do que o HTTP foi projetado. Você não está interagindo para gerenciar recursos, mas sim para invocar métodos remotos (o que não é muito estranho, mas funciona mal sem um esquema preconcebido).
Com o acima dito, e sem coragem para transformar esta resposta em um longo guia opinativo, o seguinte é um esquema URI que está em conformidade com uma abordagem de gestão de recursos:
-
%código%
-
/tasks
lista todas as tarefas paginadas -
GET
adiciona uma única tarefa
-
-
%código%
-
POST
responde com o objeto de estado de uma única tarefa -
/tasks/task/[id]
cancela / exclui uma tarefa
-
-
%código%
-
GET
lista todos os grupos de tarefas, paginados -
DELETE
adiciona um grupo de tarefas
-
-
%código%
-
/tasks/groups
responde com o estado de um grupo de tarefas -
GET
cancela / exclui o grupo de tarefas
-
Essa estrutura fala sobre recursos, não sobre o que fazer com eles. O que está sendo feito com recursos é a preocupação de outro serviço.
Outro ponto importante a ser feito é que é aconselhável não bloquear por muito tempo em um manipulador de solicitações HTTP. Assim como a interface do usuário, uma interface HTTP deve ser responsiva - em uma escala de tempo que é algumas ordens de magnitude mais lenta (porque essa camada lida com IO).
Fazer o movimento em direção à criação de uma interface HTTP que gerencia estritamente recursos provavelmente é tão difícil quanto mover o trabalho para longe de um thread da interface do usuário quando um botão é clicado. Isso requer que o servidor HTTP se comunique com outros serviços para executar tarefas, em vez de executá-las no manipulador de solicitações. Esta não é uma implementação superficial, é uma mudança de direção.
Alguns exemplos de como esse esquema de URI seria usado
Execução de uma única tarefa e acompanhamento do progresso:
-
POST
com a tarefa a executar-
/tasks/groups/group/[id]
até o objeto de respostaGET
ter valor positivo ao mostrar status / progresso atual
-
Executando uma única tarefa e aguardando sua conclusão:
-
DELETE
com a tarefa a executar-
POST /tasks
atéGET /tasks/task/[id]
ter valor positivo (provavelmente tem tempo limite, e é por isso que isso deve ser repetido)
-
Execução de um grupo de tarefas e acompanhamento do progresso:
-
completed
com o grupo de tarefas a executar-
POST /tasks
até o objeto de respostaGET /tasks/task/[id]?awaitCompletion=true
property ter valor, mostrando o status da tarefa individual (3 tarefas concluídas de 5, por exemplo)
-
Solicitando uma execução para um grupo de tarefas e aguardando sua conclusão:
-
completed
com o grupo de tarefas a executar-
POST /tasks/groups
until responde com resultado que indica conclusão (provavelmente tem timeout, e é por isso que deve ser colocado em loop)
-