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

Question

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

#1 da (18 voti)
#2 da (14 voti)
#3 da (0 voti)

19

Sto progettando un'API REST per un progetto in cui gli utenti sono sempre su uno di diversi "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 può caricare. Una volta raggiunto uno di questi limiti, gli utenti possono aggiornare i loro piani (essenzialmente pagare) per ottenere più risorse.

Desidero 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 lo risolverà, ad esempio se un utente utilizza il 100% della capacità di archiviazione e prova a caricare un file aggiuntivo, riceveranno questa risposta.

I candidati sono, IMHO:

403 Forbidden - tuttavia, vorrei distinguere tra questo caso e altri casi in cui l'utente semplicemente non ha il permesso di eseguire questa azione.
401 Unauthorized - non è una buona idea, lo stiamo usando per problemi relativi all'autenticazione.
402 Payment Required - ha senso, ma sono preoccupato di usare un codice di stato non standard ma riservato
Qualcosa di ancora meno standard come 423 Locked in quanto è improbabile che lo useremo per qualsiasi altra cosa in futuro

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

Mi chiedo quale approccio pensi che (a) funzioni meglio a lungo termine e (b) si attenga più bene ai principi RESTful.

api-design rest http

posta shevron 01.07.2015 - 11:12

fonte

3 risposte

18

Credo che 403 sia sbagliato, perché 403 è per situazioni in cui non si ha accesso alla risorsa, e non c'è assolutamente alcun modo per ottenere l'accesso. 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 è quello che è lì per.

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

BTW secondo link l'errore 429 dovrebbe contenere anche un messaggio html che descrive la natura del problema, quindi c'è un buon possibilità che all'utente venga effettivamente detto qual è il problema, se fornite tali informazioni nella vostra risposta.

risposta data 01.07.2015 - 12:07

fonte

0

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

risposta data 01.07.2015 - 11:53

fonte

Leggi altre domande sui tag api-design rest http

c cast di stile o cast di stile c ++ Quali risposte squalifica un candidato dall'assunzione durante l'intervista? [chiuso]

score 14 · Accepted Answer

Penso che 403 sia l'unica risposta ragionevole, anche se 405 Method Not Allowed o 409 Conflict potrebbero essere accettabili, non penso che siano o meno come 403 che afferma:

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity

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 era superato.