Código de status REST HTTP sugerido para 'limite de solicitação atingido'

Estou montando uma especificação para um serviço REST, parte do qual incorporará a capacidade de limitar os usuários em todo o serviço e em grupos de recursos ou em recursos individuais. Igualmente, os tempos limites para estes seriam configuráveis por recurso / grupo / serviço.

Estou apenas olhando as especificações do HTTP 1.1 e tentando decidir como vou me comunicar com um cliente que uma solicitação não será atendida porque eles atingiram seu limite.

Inicialmente, imaginei que o código do cliente 403 - Forbiddenera o único, mas este, da especificação:

A autorização não ajudará e o pedido NÃO DEVE ser repetido

me incomodou.

Na verdade, parece que 503 - Service Unavailableé melhor usar - já que permite a comunicação de um tempo de nova tentativa através do uso do Retry-Aftercabeçalho.

É possível que no futuro eu possa procurar 'comprar' mais solicitações via eCommerce (nesse caso, seria bom se o código do cliente 402 - Payment Requiredtivesse sido finalizado!) - mas acho que isso também poderia ser espremido em uma resposta 503 também.

Qual você acha que devo usar? Ou existe outro que eu não considerei?

web-services rest http

— Andras Zoltan
fonte

Respostas:

429 Pedidos demais

O usuário enviou muitas solicitações em um determinado período de tempo. Destinado ao uso com esquemas de limitação de taxa. Este código foi aceito nos códigos de status HTTP adicionais da RFC 6585 .

   The 429 status code indicates that the user has sent too many
   requests in a given amount of time ("rate limiting").

   The response representations SHOULD include details explaining the
   condition, and MAY include a Retry-After header indicating how long
   to wait before making a new request...

   Note that this specification does not define how the origin server
   identifies the user, nor how it counts requests.  For example, an
   origin server that is limiting request rates can do so based upon
   counts of requests on a per-resource basis, across the entire server,
   or even among a set of servers.  Likewise, it might identify the user
   by its authentication credentials, or a stateful cookie.

   Responses with the 429 status code MUST NOT be stored by a cache...

— Sean McMillan
fonte

Parece incrível - eu vou manter isso em mente! Ele vem com gatos grátis? Ou eles são uma extensão do protocolo?

— Andras Zoltan

HTTP gatos estado - para todas suas necessidades de status: flickr.com/photos/girliemac/sets/72157628409467125

— Sean McMillan

que acaba de rolar pelo escritório com muitas risadas e aplausos - gênio!

— Andras Zoltan

Eu fui com um 429 no final - está no rascunho, mas duvido seriamente que ele acabe sendo usado para qualquer outra coisa.

— Andras Zoltan

Até certo ponto, você é livre para fazer o que quiser com os códigos, mas eu concordo que você pode usar 503, ou se quiser 402, sem que ninguém possa reclamar que está quebrando coisas.

Editar: um purista pode dizer que você deve começar com 503 e depois mudar assim que for possível fazer pagamentos.

Um excelente complemento para isso nos comentários:

Um 4xx indica um erro do cliente que pode ser corrigido por ele executando uma determinada ação, enquanto um 5xx indica um problema no servidor que o cliente não pode ajudar a resolver. Portanto, no seu caso, um 4xx é mais apropriado, porque (i) o servidor está se comportando exatamente como deveria e (ii) o cliente pode "corrigir" o erro diminuindo a velocidade ou adquirindo mais créditos. A resolução exata pode ser indicada no corpo da resposta 429. - Mike Chamberlain há 7 horas

— Marcin
fonte

503! 503! 503! Atingiu o limite, a próxima chamada é proibida. Puro e simples ...

— yannis

@YannisRizos: Ah, mas não é proibido depois que o pagamento for feito!

— Marcin

O código de erro representa o resultado da solicitação única. Se o pagamento foi feito, em uma solicitação subsequente, é normal, como de costume ... Se você documentar o comportamento, tudo bem por mim. Ou você pode simplesmente retornar 200, com uma mensagem de erro. Mas isso não é bonito. Embora alguns possam dizer que usar códigos de erro HTTP para lógica de negócios não é bonito. Ah, bem, eu pessoalmente optaria pelo 503, o serviço não está disponível no momento - até que, claro, o 402 seja comumente suportado.

— yannis

@YannisRizos (& Marcin) - obrigado por seus comentários - achei que o 503 era o melhor; embora também entenda que as implementações de natureza RESTful podem muitas vezes se tornar confusas quando se trata de usar códigos de status HTTP. Meu ponto de vista pessoal sobre isso é usar o que o protocolo fornece, a menos que não se encaixe (o que é realmente muito raro). Neste caso, definitivamente faz!

— Andras Zoltan

Um 4xx indica um erro do cliente que pode ser corrigido por ele executando uma determinada ação, enquanto um 5xx indica um problema no servidor que o cliente não pode ajudar a resolver. Portanto, no seu caso, um 4xx é mais apropriado, porque (i) o servidor está se comportando exatamente como deveria e (ii) o cliente pode "corrigir" o erro diminuindo a velocidade ou adquirindo mais créditos. A resolução exata pode ser indicada no corpo da resposta 429.

— Mike Chamberlain