私は現在、初めてのHTTP APIを実装しています。
状況に応じて適切なコードを実装することを決心したため、HTTPステータスコードのWikipediaページを調べるのに多くの時間を費やしてきました。そのページには、420番のコードがリストされています。これは、Twitterがレート制限に使用していたカスタムコードです。
ただし、レート制限のコードはすでにあります。 429です。
そのため、ユースケースがすでにあるのに、なぜカスタムカスタムセットを設定するのか疑問に思いました。可愛いだけ?もしそうなら、どの状況が異なるステータスコードを返すことを許容できるようにしますか、そしてクライアントがそれに関して何か問題を抱えているかもしれない場合はどうしますか?
Mozillaがジョークを実装していないことをどこかで読みました418: I’m a teapot
応答。これにより、クライアントは実装するステータスコードを選択すると思います。それが本当なら、Twitterがおかしなコードを少し強調して、問題のある穏やかなコードを強化していると想像できます。
私が誤解していない限り、コード番号を適切なものにすることができます。また、慣例のみで、404は見つからないことを意味し、429はそれを容易にすることを意味しています。
インターネット全体が慣習に基づいて構築されています。それらをRFCと呼びます。 RFCに違反しても誰もあなたを逮捕したりはしませんが、あなたのサービスが他の世界と相互運用できないリスクを冒します。そして、それが起こった場合、あなたのスタートアップは顧客を獲得できず、あなたのビジネスは悪い報道を受け、あなたの株主は反乱を起こし、あなたは永久に解雇されるリスクを冒します、など.
HTTPステータスコードには 独自のIANAレジストリ があり、それぞれがそれを定義したRFC(または1つのケースではI-D)まで追跡できます。
RFC 6585 で定義されている標準の429ステータスコードに対してTwitterの奇妙な420ステータスコードの特定のケースでは、最も可能性が高いのは、後者が最近定義されたということです。 RFCの日付は2012年4月です。Twitter 以前の非推奨バージョン1では420のみを使用 のAPIであることがわかります。 現在のAPIバージョン1.1は実際には429ステータスコードを使用しています 。したがって、Twitterがこのためのステータスコードを必要とし、独自のコードを定義したことは明らかです。標準的なものが利用可能になると、彼らはそれに切り替えました。
もちろん、ベストプラクティスは、可能な限り基準に準拠することです。 RFCを読むと、ほとんどの場合「MUST」や「SHOULD」などの単語が見つかります。これらは、アプリケーションの構築時に特定の意味を持ちます。これは RFC 2119 で確認できます。
この質問 この問題について少し掘り下げます。しかし重要なことは、技術的には任意のステータスコードを作成できますが、ステータスコードの従来のスコープの範囲外にステータスコードを作成すると、APIが鈍くなり、他の人にとって難解になるだけです。それがポイントでない限り、そしてあなたが作成しているAPIが非常に素晴らしいので、あなたのリードに従うように誰もが喜んでコーディングを変更するので、とにかく何が問題なのでしょうか?
つまり、どの規格も破られる可能性があります。しかし、それを壊した場合、そうすることによって何を得るか、または失うか?
一般に、何か別のことを行うことができるが、標準が標準を暗示する場合、確立された標準から離れる非常に強力で説得力のある理由がない限り、標準に従うことをお勧めします。 Twitterの場合420: Enhance Your Calm
彼らが直面しているユニークな状況を明確に伝える応答コードを作成しています。これは、サービスを拒否せずに要求を遅くしています。