Devo creare i miei codici di stato HTTP? (a Twitter 420: Migliora la tua calma)

Attualmente sto implementando un'API HTTP, la mia prima volta in assoluto.

Ho passato molto tempo a guardare la pagina di Wikipedia per i codici di stato HTTP, perché sono determinato a implementare i codici giusti per le giuste situazioni. In quella pagina è elencato un codice con il numero 420, che è un codice personalizzato che Twitter utilizzava per limitare le tariffe.

Tuttavia, esiste già un codice per limitare la velocità. Sono le 429.

Questo mi ha portato a chiedermi perché ne avrebbero impostato uno personalizzato, quando esiste già un caso d'uso. È solo carino? E in caso affermativo, quali circostanze renderebbero accettabile la restituzione di un codice di stato diverso e quali potrebbero essere i problemi con i client?

Ho letto da qualche parte che Mozilla non implementa la 418: I’m a teapotrisposta scherzosa , il che mi fa pensare che i clienti scelgano quali codici di stato implementano. Se questo è vero, allora posso immaginare che il piccolo buffo di Twitter possa migliorare il tuo codice di calma.

A meno che non mi sbagli, e possiamo appropriarci di qualsiasi numero di codice per indicare quello che ci piace, e che solo la convenzione impone che 404 significa non trovato, e 429 significa prendersela comoda.

Tutta Internet è basata su convenzioni. Li chiamiamo RFC. Mentre nessuno verrà e ti arresterà se violerai una RFC, corri il rischio che il tuo servizio non interagisca con il resto del mondo. E se ciò accade, corri il rischio che la tua startup non ottenga alcun cliente, che la tua azienda ottenga cattiva stampa, che i tuoi azionisti si ribellino, che venga licenziato in modo permanente, ecc.

I codici di stato HTTP hanno il proprio registro IANA , ognuno riconducibile all'RFC (o, in un caso, all'ID) che lo ha definito.

Nel caso particolare dello strano codice di stato 420 di Twitter rispetto al codice di stato 429 standard definito in RFC 6585 , la spiegazione più probabile è che quest'ultima sia stata definita solo di recente; la RFC risale ad aprile 2012. Vediamo che Twitter utilizza solo 420 nella precedente versione deprecata 1 della sua API; l'attuale versione 1.1 dell'API utilizza effettivamente il codice di stato 429 . Quindi è chiaro che Twitter aveva bisogno di un codice di stato per questo e definito il proprio; una volta disponibile uno standard, sono passati ad esso.

La migliore pratica, ovviamente, è attenersi il più possibile agli standard. Quando leggi gli RFC, troverai quasi sempre parole come "DEVE" e "DOVREBBE"; questi hanno significati specifici quando si crea l'applicazione, che è possibile trovare in RFC 2119 .

Questa domanda approfondisce un po 'il problema. Ma il fatto è che, sebbene sia possibile creare tecnicamente qualsiasi codice di stato desiderato, la creazione di un codice di stato al di fuori dell'ambito tradizionale dei significati del codice di stato rende l'API più ottusa e arcana per gli altri. A meno che non sia questo il punto, e l'API che stai creando è così assolutamente sorprendente che tutti cambieranno volentieri la loro codifica per seguire il tuo esempio, cosa importa comunque?

Si riduce a questo: qualsiasi standard può essere infranto. Ma se lo rompi, cosa guadagni o perdi facendo così?

In generale, nei casi in cui è possibile fare qualcosa di diverso ma gli standard implicano standard, è meglio aderire agli standard a meno che non vi sia una ragione molto forte e convincente per allontanarsi dagli standard stabiliti. Nel caso di Twitter 420: Enhance Your Calmstanno creando un codice di risposta che parla chiaramente di una situazione unica che devono affrontare. Il che sta rallentando le richieste senza negare il servizio.