独自のHTTPステータスコードを作成する必要がありますか？（アラカルトTwitter 420：穏やかさを高める）

私は現在、初めてのHTTP APIを実装しています。

適切な状況に適切なコードを実装することを決心しているため、HTTPステータスコードのウィキペディアページを見るのに多くの時間を費やしてきました。そのページには、420のコードがリストされています。これは、Twitterがレート制限に使用していたカスタムコードです。

ただし、すでにレート制限のコードがあります。429です。

これにより、ユースケースが既に存在するのに、なぜカスタムに設定するのか疑問に思いました。それはただかわいいだけですか？もしそうなら、異なる状況コードを返すことがどのような状況で受け入れられるようになりますか？また、クライアントに問題がある場合はどうなりますか？

Mozillaがジョーク418: I’m a teapot応答を実装していないことをどこかで読んだので、クライアントは実装するステータスコードを選択すると思います。それが本当なら、Twitterの面白おかしい小さなコードがあなたの落ち着いたコードの問題を改善していると想像できます。

誤解しない限り、任意のコード番号を使用して好きなものを意味することができます。この規約では、404が見つからないことを意味し、429は簡単にすることを意味します。

インターネット全体は、慣例に基づいて構築されています。それらをRFCと呼びます。RFCに違反した場合、だれもあなたを逮捕することはありませんが、あなたはあなたのサービスが他の世界と相互運用しないというリスクを負います。そして、そうなった場合、スタートアップが顧客を獲得できず、ビジネスが悪い報道を受け、株主が反抗し、永久に解雇されるなどのリスクを冒します。

HTTPステータスコードには独自のIANAレジストリがあり、各レジストリはそれを定義したRFC（ある場合にはID）に遡って追跡できます。

Twitterの奇妙な420ステータスコードとRFC 6585で定義された標準429ステータスコードの特定のケースでは、最も可能性の高い説明は後者が最近定義されただけだということです。RFCの日付は2012年4月です。Twitter は、APIの以前の非推奨バージョン1で420のみを使用していることがわかります。現在のAPIバージョン1.1は、429ステータスコードを実際に使用します。したがって、Twitterがこのためのステータスコードを必要とし、独自に定義したことは明らかです。標準のものが利用可能になると、彼らはそれに切り替えました。

もちろん、ベストプラクティスは、できるだけ標準に近づけることです。RFCを読むと、ほとんどの場合「MUST」や「SHOULD」などの単語が見つかります。これらは、RFC 2119に記載されているアプリケーションを構築するときに特定の意味を持ちます。

この質問では、この問題について少し掘り下げます。ただし、必要なステータスコードは技術的に作成できますが、ステータスコードの意味の従来の範囲外のステータスコードを作成すると、APIがより鈍くなり、他の人にとってわかりにくいものになります。それがポイントでない限り、そしてあなたが作成しているAPIは非常に驚くべきものであるため、誰もが喜んでコーディングを変更してあなたのリードに従うようになります。

要するにこれは、標準が破られる可能性があるということです。しかし、あなたがそれを破るなら、あなたはそうすることによって何を得るか失うのですか？

一般に、何か別のことができるが標準は標準を暗示している場合、確立された標準から遠ざかる非常に強力で説得力のある理由がない限り、標準に従うことをお勧めします。Twitterの場合、420: Enhance Your Calm彼らは彼らが直面しているユニークな状況を明確に伝える応答コードを作成しています。サービスを拒否せずにリクエストを遅くしています。