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

Question

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

#1 da (30 voti)
#2 da (2 voti)

23

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

Ho passato molto tempo a guardare la pagina di Wikipedia per i codici di stato HTTP, perché sono determinato a implementare i codici corretti per le situazioni giuste. In questa pagina è presente un codice con il numero 420, che è un codice personalizzato utilizzato da Twitter per la limitazione della velocità.

C'è già un codice per la limitazione della velocità, però. È 429.

Questo mi ha portato a chiedermi perché ne avrebbero impostato uno personalizzato, quando esiste già un caso d'uso. È solo carino? E se sì, allora 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 risposta joke 418: I’m a teapot , il che mi fa pensare che i clienti scelgano quali codici di stato implementano. Se è vero, allora posso immaginare che il piccolo divertente di Twitter migliori il tuo codice calmo e sia problematico.

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

api-design http

posta Max Bucknell 11.11.2013 - 00:47

fonte

2 risposte

2

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

Si riduce a questo: qualsiasi standard può essere rotto. 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 strong e convincente per deviare dagli standard stabiliti. Nel caso del 420: Enhance Your Calm di Twitter, stanno creando un codice di risposta che parla chiaramente di una situazione unica che devono affrontare. Che sta rallentando le richieste senza negare il servizio.

risposta data 11.11.2013 - 01:03

fonte

Leggi altre domande sui tag api-design http

Come gestire un TODO in una richiesta pull? Come strutturare correttamente un progetto in winform?

score 30 · Accepted Answer

L'intero Internet è costruito su convenzioni. Li chiamiamo RFC. Mentre nessuno arriverà e ti arresterà se violerai un RFC, correrai il rischio che il tuo servizio non interagisca con il resto del mondo. E se che accade, corri il rischio che la tua startup non ottenga alcun cliente, che la tua azienda subisca una cattiva stampa, che i tuoi azionisti si ribellano, che tu venga licenziato definitivamente, ecc.

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

Nel caso particolare dello strano codice di stato 420 di Twitter rispetto al codice di stato standard 429 definito in RFC 6585 , il più probabile spiegazione è che quest'ultimo è stato definito solo di recente; la RFC risale ad aprile 2012. Vediamo che Twitter utilizza solo 420 nella precedente versione deprecata 1 dei suoi API; l'attuale versione API 1.1 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 RFC, troverai quasi sempre parole come "MUST" e "DOVREBBE"; questi hanno significati specifici quando crei la tua applicazione, che puoi trovare in RFC 2119 .