Codice di stato HTTP consigliato per la risposta "limite del piano superato"

Sto progettando un'API REST per un progetto in cui gli utenti sono sempre su uno dei numerosi "piani" - ogni piano definisce alcuni limiti di risorse, come il numero massimo di utenti che un account può avere o il numero massimo di dati che possono caricare. Una volta raggiunto uno di questi limiti, gli utenti possono aggiornare i propri piani (essenzialmente pagare) per ottenere più risorse.

Voglio restituire un codice di stato speciale che indica una situazione in cui l'azione non può essere eseguita a causa dei limiti delle risorse dell'account e l'aggiornamento del piano risolverà questo problema, ad esempio se un utente utilizza il 100% della capacità di archiviazione e prova a caricare un file aggiuntivo , otterranno questa risposta.

I candidati sono, IMHO:

• 403 Forbidden - tuttavia, vorrei distinguere tra questo caso e altri casi in cui l'utente non dispone semplicemente dell'autorizzazione per eseguire questa azione.

• 401 Unauthorized - non è una buona idea, lo stiamo usando per problemi relativi all'autenticazione.

• 402 Payment Required - ha un senso, ma sono preoccupato per l'uso di un codice di stato non standard ma riservato

• Qualcosa di ancora meno standard come è 423 Lockedimprobabile che lo useremo per qualsiasi altra cosa in futuro

Un'altra opzione è quella di andare con qualcosa di molto standard come 403ma indicare i dettagli dell'errore nel corpo della risposta.

Mi chiedo quale approccio ritieni possa (a) funzionare meglio a lungo termine e (b) aderirebbe meglio ai principi RESTful.

Penso che 403 sia l'unica risposta ragionevole, anche se 405 Metodo non consentito o 409 Conflitto potrebbero essere accettabili, non credo nemmeno che siano buoni come 403 che afferma:

Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non sarà di aiuto e la richiesta NON DOVREBBE essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico il motivo per cui la richiesta non è stata soddisfatta, DOVREBBE descrivere il motivo del rifiuto nell'entità

Se si restituisce un errore 403, includerà alcune informazioni sul motivo per cui la risorsa è stata negata - l'autorizzazione non valida è solo il caso più comune, i limiti superati non sono molto diversi - non si dispone dell'autorizzazione perché il limite è stato superato.

Credo che 403 sia sbagliato, perché 403 è per situazioni in cui non si ottiene l'accesso alla risorsa e non esiste alcun modo per accedervi. Per i tuoi clienti, c'è ovviamente un modo per ottenere l'accesso: pagare.

401 è veramente sbagliato, perché non solo lo stai usando per l'autenticazione, ma è per questo che è lì.

Dato che stai scrivendo un'API, suppongo che qualcun altro dovrà scrivere il codice che utilizza l'API e che tale persona deve leggere le specifiche dell'API. Potresti andare con 429 "Troppe richieste". Di solito è inteso per limitare le tariffe (dove un cliente può fare 100 richieste al giorno, per esempio), ma si applica ragionevolmente alla tua situazione. 402 (pagamento richiesto) sarebbe anche accettabile, penso. Dipende dagli strumenti che ti aspetti che le persone utilizzino per usare la tua API. 429 ha il rischio che uno strumento intelligente tenti di inviare meno richieste al minuto / ora / giorno e non ci riesca mai.

A proposito secondo https://tools.ietf.org/html/rfc6585 l'errore 429 dovrebbe anche contenere un messaggio html che descriva la natura del problema, quindi c'è una buona probabilità che l'utente venga effettivamente informato su quale sia il problema, se si fornisce tali informazioni nella tua risposta.

WebDAV utilizza l' archiviazione insufficiente HTTP 507 per questo e include un codice di errore aggiuntivo per la quota superata nel corpo della richiesta, per distinguerlo da altri tipi di limitazioni di archiviazione.