Codice di stato REST HTTP suggerito per 'limite di richiesta raggiunto'

Naviga le tue risposte
41

Sto mettendo insieme una specifica per un servizio REST, una parte della quale includerà la capacità di limitare gli utenti a livello di servizio e su gruppi di risorse singole o individuali. Allo stesso modo, i timeout per questi sarebbero configurabili per risorsa / gruppo / servizio.

Sto solo esaminando la specifica HTTP 1.1 e sto cercando di decidere come comunicare a un cliente che una richiesta non verrà soddisfatta perché ha raggiunto il limite.

Inizialmente ho capito che il codice cliente 403 - Forbidden era quello, ma questo, dalla specifica:

Authorization will not help and the request SHOULD NOT be repeated

mi ha infastidito.

In realtà sembra che 503 - Service Unavailable sia uno migliore da usare, poiché consente la comunicazione di un tempo di ripetizione attraverso l'uso dell'intestazione Retry-After .

È possibile che in futuro potrei cercare di supportare "l'acquisto" di più richieste tramite eCommerce (nel qual caso sarebbe bello se il codice cliente 402 - Payment Required fosse stato finalizzato!) - ma immagino che questo potrebbe essere ugualmente schiacciato in una risposta 503.

Quale pensi che dovrei usare? O c'è un altro che non ho considerato?

    
posta Andras Zoltan 05.01.2012 - 12:36
fonte

2 risposte

70

429 troppe richieste

L'utente ha inviato troppe richieste in un dato periodo di tempo. Destinato all'uso con schemi di limitazione della velocità. Questo codice è stato accettato in RFC 6585 Codici di stato HTTP aggiuntivi . 

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...
    
risposta data 05.01.2012 - 17:22
fonte
7

In una certa misura, sei libero di fare ciò che ti piace con i codici, ma sono d'accordo che tu possa usare 503 , o se vuoi 402 , senza che nessuno possa lamentarsi che stai rompendo le cose.

Modifica: un purista potrebbe dire che dovresti iniziare con 503, quindi cambiare una volta che è possibile effettuare pagamenti.

Un'eccellente aggiunta a questo nei commenti:

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

    
risposta data 05.01.2012 - 12:48
fonte

Leggi altre domande sui tag

Ci sono degli svantaggi nell'assumere un lavoro in cui userò un linguaggio di programmazione unico? [chiuso] Come posso passare da uno sviluppatore software a un gestore software o team leader? [chiuso]