ステータスコードについて解説している記事を、勉強を兼ねて翻訳してみました。ところどころ自信がないので間違いなどあればご指摘いただけますと幸いです。ステータスコードには少なからず混乱や戸惑いを感じることがある。私は長年に亘ってストレスを抱えた開発者から次のような相談を受けている。使おうとしているし、向かいの席のひとは新しいステータスコードを定義しようとしています。ステータスコードのことやその使い方について掘り下げてみましょう。ステータスコードは構造化されている。1桁目はレスポンスの種類を示し、他2桁はそのレスポンスを具体的にどのように処理するかを示す。定義済みのレスポンスの種類は次の通り。ステータスコードで、成功したレスポンスを示す。ヘッダーに指定されたURLにあるリソースが作成されたことを示す。ステータスコードで、サーバーの処理によるものではなく、リクエストに問題があることを意味する。リクエストがサーバーの状態と競合していることをクライアントに伝えており、再度リクエストを送信する前に競合を解決する必要がある。1桁目の数字はそれ自身が意味を持っているため、ステータスコードの受け取り側はそれを調べてレスポンスの意味を理解できるが、どのように処理するべきかは明確ではない。これにより、新しく定義されたステータスコードを一般的に処理できるように適切に格下げすることができる(きちんと設計されていれば)。リソースに適用される可能性があると定義されていることを理解することも重要である。この訳が相応しいかどうかちょっと自信がない...)これを知ることは混乱の原因を明らかにする。アプリケーション固有のセマンティクスを汎用的なセマンティクスにマッピングすることは困難であり、間違えやすいやり方である。アプリケーションを一連のステータスコードに「一致させる」ことは苦労を招くだけである。これはやってはいけない。ウィジェットが逆順であることを意味する」ということを述べようとしている仕様を見かけることは残念ながらよくあることである。これは、実際のところステータスコードのセマンティクスを再定義することである(汎用的ということを思い出して)。プライベートバージョンを作成することになり、コードに悪い影響を及ぼす可能性がある(もともとそういう決まりがないのであれば)。これはいい取り組みではあるが、悪いプラクティスである。クライアントが受け取るかもしれない一連のステータスコードは、彼らが把握しているひと握りの一覧より遥かに多いものである。返す可能性があるためである。代わりに、アプリケーションはメソッドやリソースの表現の観点からリソースの振る舞いを定義するべきである。することでその状態を更新できる。受け取るステータスコードは、すでに定義されており、広く知られている。一覧化したり、改良する必要はない。セマンティクスは特に汎用的であるため、特別なケースを示す。次に述べることは理にかなっている。系のステータスコードは、成功を示すものとして使われることに留意する。それによって、将来のステータスコードとの前方互換性を保つことができる。固有のステータスコードを返すことを説明する必要があるかもしれない。