Devo criar meus próprios códigos de status HTTP? (no Twitter 420: melhore a sua calma)

Atualmente, estou implementando uma API HTTP, minha primeira vez.

Passei muito tempo procurando na página da Wikipedia por códigos de status HTTP, porque estou determinado a implementar os códigos certos para as situações certas. Listado nessa página, está um código com o número 420, que é um código personalizado que o Twitter costumava usar para limitar a taxa.

Já existe um código para limitar a taxa. São 429.

Isso me levou a pensar por que eles definiriam um personalizado, quando já existe um caso de uso. Isso é apenas ser fofo? Em caso afirmativo, quais circunstâncias tornariam aceitável retornar um código de status diferente? E se houver algum problema com os clientes?

Li em algum lugar que o Mozilla não implementa a 418: I’m a teapotresposta à piada , o que me faz pensar que os clientes escolhem quais códigos de status eles implementam. Se isso for verdade, posso imaginar que o pequeno humor engraçado do Twitter aprimora seu código calmo como problemático.

A menos que eu esteja enganado, e possamos apropriar-se de qualquer número de código para significar o que quisermos, e que apenas a convenção determina que 404 significa não encontrado e 429 significa calma.

Toda a Internet é construída sobre convenções. Nós os chamamos de RFCs. Embora ninguém venha prendê-lo se você violar uma RFC, você corre o risco de que seu serviço não interfira com o resto do mundo. E se isso acontecer, você corre o risco de sua startup não receber clientes, seus negócios ficarem com má impressão, seus acionistas revoltados, sua demissão permanente etc.

Os códigos de status HTTP têm seu próprio registro IANA , cada um rastreável até a RFC (ou, em um caso, ID) que a definiu.

No caso específico do estranho código de status 420 do Twitter, em comparação com o código de status padrão 429 definido na RFC 6585 , a explicação mais provável é que o último foi definido apenas recentemente; a RFC data de abril de 2012. Vemos que o Twitter usa apenas 420 na versão anterior reprovada 1 de sua API; a atual versão da API 1.1 realmente usa o código de status 429 . Portanto, é claro que o Twitter precisava de um código de status para isso e definiu o seu próprio; Uma vez disponível um padrão, eles mudaram para ele.

A melhor prática, é claro, é manter-se o mais próximo possível dos padrões. Quando você lê RFCs, quase sempre encontra palavras como "DEVE" e "DEVE"; estes têm significados específicos ao criar seu aplicativo, que você pode encontrar na RFC 2119 .

Esta questão investiga um pouco a questão. Mas o problema é que, embora você possa criar tecnicamente qualquer código de status desejado, a criação de um código de status fora do escopo tradicional dos significados do código de status apenas torna sua API mais obtusa e misteriosa para os outros. A menos que esse seja o ponto, e a API que você está criando é tão incrível que todos terão prazer em mudar sua codificação para seguir seu exemplo. O que importa, certo?

Tudo se resume a isso: qualquer padrão pode ser quebrado. Mas se você quebrar, o que você ganha ou perde ao fazer isso?

Em geral, nos casos em que você pode fazer algo diferente, mas os padrões implicam padrões, é melhor aderir aos padrões, a menos que haja uma razão muito forte e convincente para se desviar dos padrões estabelecidos. No caso do Twitter, 420: Enhance Your Calmeles estão criando um código de resposta que claramente fala de uma situação única que eles enfrentam. O que está diminuindo as solicitações sem negar o serviço.