É errado retornar 202 “Aceito” em resposta ao HTTP GET?

Tenho um conjunto de recursos cujas representações são criadas preguiçosamente. O cálculo para construir essas representações pode levar de alguns milissegundos a algumas horas, dependendo da carga do servidor, do recurso específico e da fase da lua.

A primeira solicitação GET recebida para o recurso inicia a computação no servidor. Se o cálculo for concluído em alguns segundos, a representação computada será retornada. Caso contrário, um código de status 202 "Aceito" é retornado e o cliente deve pesquisar o recurso até que a representação final esteja disponível.

O motivo para esse comportamento é o seguinte: Se um resultado estiver disponível em alguns segundos, ele precisa ser recuperado o mais rápido possível; caso contrário, quando estiver disponível, não é importante.

Devido à memória limitada e ao grande volume de solicitações, nem NIO nem long polling são uma opção ( ou seja, não consigo manter conexões abertas o suficiente, nem mesmo caber todas as solicitações na memória; uma vez "alguns segundos" passaram, eu persisto os pedidos em excesso). Da mesma forma, as limitações do cliente são tais que eles não podem lidar com um retorno de chamada de conclusão. Por fim, observe que não estou interessado em criar um recurso de "fábrica" ​​para o qual seja feito um POST, pois as viagens extras significam que falhamos na restrição de tempo real por partes mais do que o desejado (além disso, é uma complexidade extra; também, este é um recurso que beneficiar do armazenamento em cache).

Imagino que haja alguma controvérsia sobre o retorno de um código de status 202 "Aceito" em resposta a uma solicitação GET, visto que nunca vi isso na prática e seu uso mais intuitivo é em resposta a métodos inseguros, mas nunca encontrou algo especificamente desencorajador. Além disso, não estou preservando a segurança e a idempotência?

Então, o que as pessoas pensam sobre essa abordagem?

EDIT : Devo mencionar que isso é para uma chamada API da web de negócios - não para navegadores.

Se for para uma API bem definida e documentada, 202soa exatamente o que está acontecendo.

Se for para a Internet pública, eu ficaria muito preocupado com a compatibilidade do cliente. Já vi tantos if (status == 200)hard-coded .... Nesse caso, eu retornaria a 200.

Além disso, o RFC não faz nenhuma indicação de que o uso de 202 para uma solicitação GET seja errado, embora faça distinções claras em outras descrições de código (por exemplo, 200).

A solicitação foi aceita para processamento, mas o processamento não foi concluído.

Fizemos isso para um aplicativo recente, um cliente (aplicativo personalizado, não um navegador) postou uma consulta e o servidor retornou 202 com um URI para o "trabalho" sendo postado - o cliente usaria esse URI para pesquisar o resultado - isso parece se encaixar perfeitamente com o que estava sendo feito.

A coisa mais importante aqui é documentar como seu serviço / API funciona e o que uma resposta de 202 significa.

Pelo que me lembro - GET deve retornar um recurso sem modificar o servidor. Talvez a atividade seja registrada ou algo assim, mas a solicitação deve ser reiniciada com o mesmo resultado.

O POST, por outro lado, é uma solicitação para alterar o estado de algo no servidor. Insira um registro, exclua um registro, execute um trabalho, algo assim. 202 seria apropriado para um POST que retornou, mas não foi concluído, mas não é realmente uma solicitação GET.

É tudo muito puritano e não é bem praticado na natureza, então você provavelmente está seguro ao retornar 202. GET deve retornar 200. O POST pode retornar 200 se for concluído ou 202 se não for feito.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

No caso de um recurso que deveria ter uma representação de uma entidade que é claramente especificada por um ID (ao contrário de um recurso de "fábrica", conforme descrito na pergunta), recomendo ficar com o método GET e, em um situação em que a entidade / representação não está disponível devido à criação preguiçosa ou qualquer outra situação temporária, use o código de resposta 503 Serviço indisponível que é mais apropriado e foi realmente projetado para situações como esta.

Os motivos para isso podem ser encontrados nas RFCs para o próprio HTTP (verifique a descrição do código de resposta 503), bem como em vários outros recursos.

Compare com o código de status HTTP para páginas temporariamente indisponíveis . Embora essa pergunta seja sobre um caso de uso diferente, na verdade ela está relacionada ao mesmo recurso do HTTP.