Código de status HTTP REST sugerido para 'limite de solicitações atingido'

41

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 ou recursos individuais. Igualmente, os tempos limite para estes seriam configuráveis por recurso / grupo / serviço.

Estou apenas examinando as especificações HTTP 1.1 e tentando decidir como comunicarei a um cliente que uma solicitação não será atendida porque atingiu seu limite.

Inicialmente, percebi que o código do cliente 403 - Forbidden era o único, mas isso, a partir da especificação:

Authorization will not help and the request SHOULD NOT be repeated

me incomodou.

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

É possível que, no futuro, eu procure apoiar a 'compra' de mais pedidos via eCommerce (caso em que seria bom se o código do cliente 402 - Payment Required tivesse sido finalizado!) - mas eu acho que isso poderia ser igualmente espremido em uma resposta 503 também.

Qual você acha que eu deveria usar? Ou há outro que eu não considerei?

    
por Andras Zoltan 05.01.2012 / 12:36
fonte

2 respostas

70

429 Solicitações demais

O usuário enviou muitas solicitações em um determinado período de tempo. Destinado a uso com esquemas limitadores de taxa. Este código foi aceito em RFC 6585 Códigos de Status HTTP Adicionais .

The429statuscodeindicatesthattheuserhassenttoomanyrequestsinagivenamountoftime("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...
    
por 05.01.2012 / 17:22
fonte
7

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

Editar: Um purista pode dizer que você deve começar com 503, depois mudar uma vez que é possível fazer pagamentos.

Um excelente acréscimo a isso nos comentários:

A 4xx indicates an error by the client that can be fixed by them taking a certain action, whereas a 5xx indicates a problem on the server that the client can't help resolve. So in your case, a 4xx is more appropriate, because the (i) the server is behaving exactly as it should, and (ii) the client can "fix" the error by either slowing down or purchasing more credits. The exact resolution can be indicated in the body of the 429 response. – Mike Chamberlain 7 hours ago

    
por 05.01.2012 / 12:48
fonte