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

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

Sto solo esaminando le specifiche HTTP 1.1 e provando a decidere come comunicherò a un client che una richiesta non sarà soddisfatta perché hanno raggiunto il loro limite.

Inizialmente ho pensato che il codice client 403 - Forbiddenfosse quello, ma questo, dalle specifiche:

L'autorizzazione non aiuterà e la richiesta NON DOVREBBE essere ripetuta

mi ha infastidito.

In realtà sembra che 503 - Service Unavailablesia migliore da usare, poiché consente la comunicazione di un tempo di ripetizione tramite l'uso Retry-Afterdell'intestazione.

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

Quale pensi che dovrei usare? O ce n'è un altro che non ho preso in considerazione?

web-services rest http

— Andras Zoltan
fonte

Risposte:

429 Troppe richieste

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

   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

Sembra fantastico - lo terrò a mente! Viene con i gatti liberi? O sono un'estensione del protocollo?

— Andras Zoltan,

Gatti di stato HTTP - per tutte le esigenze di stato: flickr.com/photos/girliemac/sets/72157628409467125

— Sean McMillan

che ha appena fatto il giro dell'ufficio con molte risate e applausi - genio!

— Andras Zoltan,

Sono andato con un 429 alla fine - è nella bozza delle specifiche ma dubito seriamente che finirà per essere utilizzato per qualsiasi altra cosa.

— Andras Zoltan,

In una certa misura, sei libero di fare quello che ti piace con i codici, ma sarei d'accordo che puoi 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 passare una volta che è possibile effettuare pagamenti.

Un'ottima aggiunta a questo nei commenti:

Un 4xx indica un errore del client che può essere risolto da loro eseguendo una determinata azione, mentre un 5xx indica un problema sul server che il client non può aiutare a risolvere. Quindi, nel tuo caso, un 4xx è più appropriato, perché (i) il server si comporta esattamente come dovrebbe, e (ii) il client può "correggere" l'errore rallentando o acquistando più crediti. La risoluzione esatta può essere indicata nel corpo della risposta 429. - Mike Chamberlain 7 ore fa

— Marcin
fonte

503! 503! 503! Raggiunto il limite, la chiamata successiva è vietata.

— Chiaro

@YannisRizos: Ah, ma non è vietato una volta effettuato il pagamento!

— Marcin,

Il codice di errore rappresenta il risultato della singola richiesta. Se il pagamento è stato effettuato, su una richiesta successiva è come al solito ... Se documenti il comportamento, va bene per me. Oppure potresti semplicemente restituire 200, con un messaggio di errore. Ma non è carino. Anche se alcuni potrebbero dire che usare i codici di errore HTTP per la logica aziendale non è carino. Ah bene, andrei personalmente con 503, il servizio non è disponibile in questo momento - fino a quando ovviamente 402 non è comunemente supportato.

— yannis,

@YannisRizos (& Marcin) - grazie per i tuoi commenti - ho pensato che 503 fosse il migliore con cui andare; pur comprendendo anche che le implementazioni di natura RESTful possono spesso sporcarsi di essere lanosi quando si tratta del loro uso dei codici di stato HTTP. Il mio punto di vista personale su questo è quello di utilizzare ciò che il protocollo fornisce a meno che non si adatti (che in realtà è molto raro). In questo caso, lo fa sicuramente!

— Andras Zoltan,

Un 4xx indica un errore del client che può essere risolto da loro eseguendo una determinata azione, mentre un 5xx indica un problema sul server che il client non può aiutare a risolvere. Quindi, nel tuo caso, un 4xx è più appropriato, perché (i) il server si comporta esattamente come dovrebbe, e (ii) il client può "correggere" l'errore rallentando o acquistando più crediti. La risoluzione esatta può essere indicata nel corpo della risposta 429.

— Mike Chamberlain,