『HTTPステータスコード』で会話をしよう

はじめに

初めまして。かるでねと申します。
普段色々と記事を書いたり開発したりしています。

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！

今回はHTTPステータスコードを使用して会話ができないか考えていきたいと思います。
「HTTPステータスコードで会話することで、より効率的な会話ができるはず」という信念の元記事を書いたので、ぜひ楽しんでいってください。

この記事は以下のPodcastの1エピソード内の一瞬出てきた「HTTPステータスコードで会話する」をきっかけにまとめています。

HTTPステータスコードとは？

そもそもHTTPステータスコードがわからない方もいると思うので、その説明からしていこうと思います。
mozillaのサイトでは、HTTPステータスコードについて以下のように書かれています。

HTTP のレスポンスステータスコードは、特定の HTTP リクエストが正常に完了したどうかを示します。

wikipediaでは以下のように書かれています。

HTTPステータスコードは、HTTPにおいてWebサーバからのレスポンスの意味を表現する3桁の数字からなるコードである。

要はクライアント（ブラウザやAPIクライアント）とサーバー間でやり取りされるリクエストとレスポンスの結果を示す3桁の番号です。

以下のように5つのカテゴリに分類されていて、さらにその中で番号によって意味していることが異なります。

1xx: 情報レスポンス

• 100 Continue
  • クライアントがリクエストを続行しても良い。
• 101 Switching Protocols
  • サーバーがプロトコルの切り替えを承認した。

2xx: 成功レスポンス

• 200 OK
  • リクエストが成功し、通常はリクエストに対応するリソースが返される。
• 201 Created
  • リクエストが成功し、新しいリソースが作成された。
• 204 No Content
  • リクエストは成功したが返す内容がない。

3xx: リダイレクト

• 301 Moved Permanently
  • リクエストしたリソースが恒久的に新しいURLに移動した。
• 302 Found
  • 一時的に別のURLにリソースが移動している。
• 304 Not Modified
  • キャッシュされたリソースが最新であるため、再取得の必要がない。

4xx: クライアントエラー

• 400 Bad Request
  • サーバーがリクエストを理解できない（不正なリクエスト）。
• 401 Unauthorized
  • 認証が必要なリソースにアクセスしようとしたが、認証が失敗した。
• 403 Forbidden
  • 認証は成功したが、アクセス権がない。
• 404 Not Found
  • リクエストしたリソースが存在しない。
• 405 Method Not Allowed
  • リクエストしたメソッドが許可されていない。

5xx: サーバーエラー

• 500 Internal Server Error
  • サーバー内でなエラーが発生した。
• 501 Not Implemented
  • サーバーがリクエストされた機能をサポートしていない。
• 502 Bad Gateway
  • サーバーがゲートウェイまたはプロキシとして機能している時に、上流のサーバーから不正なレスポンスを受け取った。
• 503 Service Unavailable
  • サーバーが過負荷やメンテナンス中のため、サービスを利用できない。
• 504 Gateway Timeout
  • ゲートウェイやプロキシが上流のサーバーからのレスポンスをタイムアウトした。

HTTPステータスコードで会話するとは？

「HTTPステータスコードで会話する」とはどういうことか説明します。
簡単に言えば、何か返答する時に「OK」や「Yes」と返す代わりに、「200」と返すということです。

上司：「この前お願いしていた〇〇の開発終わってる？」
自分：「200」

上司：「この前先方からもらった資料ってどこにあるかわかる？」
自分：「404」

こんな感じですね。
どうでしょう？
イメージできましたかね？

HTTPステータスコードで会話するメリット

HTTPステータスコードで返答すると、「そっけない」と感じたり、「逆に不便そう」といった感想を持つ方がいらっしゃると思います。
確かに、物事には二面性がありメリットとデメリットが存在します。
デメリットはいくつも重い浮かぶと思うので、メリットだけまとめていきたいと思います。

HTTPステータスコードを覚えられる

「200」や「404」、「500」といった、よく使われるHTTPステータスコードは自然と覚えることができます。
一方、普段あまり使用されないHTTPステータスコードの場合、なかなか覚えられず毎回検索している思います。
HTTPステータスコードを用いて会話することで、普段から様々なHTTPステータスコードを使用することで自然と覚えることができます。
これは業務においてもメリットになり得るポイントです。

返答文を考えなくて良い

上司と会話する時、敬語などを入れ込み丁寧な返答文を考えている人は多いと思います。
そこで、HTTPステータスコードを使用して「はい」なら「200」、「いいえ」なら「403」などと決めてしまえば返答文を考える必要がありません。
以下のように返答のあとんにリンクなども渡せてしまいます。

上司：「この前お願いしていた〇〇の開発終わってる？」
自分：「200。https://qiita.com/cardene 」

会社ならば、HTTPステータスコードを使用するときめて共通認識にすれば、誰でも気兼ねなく使用することができます。
もし「敬語で話せ！」という方がいましたら、「レスポンスが敬語のはずないでしょう！」と返しましょう。
これにより業務内の返信時間が短縮されます。

雑談のきっかけになる

例えば、普段あまり使われないHTTPステータスコードを返信で使用したとします。
それをきっかけに「HTTPステータスコード知らなかった！」や「このHTTPステータスコードをこの返信で使用できるのは考えたことなかった！」のように、コミュニケーションのきっかけになります。
個人的には雑談はあるに越したことはないと思っているので、社内のコミュニケーションを円滑化させることができるのはメリットだと思っています。

実践

では、各HTTPステータスコードを使用して、「どのような場面で使用するか」、「どのような意味として使用するか」を考えていきたいと思います。

1xx

100 Continue

その時点までの処理に問題がなく、クライアントはリクエストを継続してよいという暫定レスポンスです。
またもしリクエストが完了している場合はレスポンスを無視してよいことを示します。

途中で指示を確認して作業を継続してよいか確認する場合などに使用できそうです。

自分：「設計書〇〇まで進めたので内容問題ないか確認していただきたいのですが、このまま続けて進めても大丈夫でしょうか？」
上司：「100」

101 Switching Protocols

クライアントがリクエストの中で「Upgrade」ヘッダーを使ってプロトコルの変更を要求した場合に、サーバーがその要求に応じてプロトコルを変更することを示します。

上司からプロジェクトの進め方や使用ツールの変更指示がきたとき、作業の進め方や使用ツールを変更することを承認して切り替えに応じる場面などで使用できます。

上司：「この作業はExcelじゃなくて、スプシに切り替えて進めてほしい。」
自分: 「101」

102 Processing

サーバーはリクエストを受け取って処理しているが、まだレスポンスを提供できないことを示します。

上司が進捗を尋ねているが、作業がまだ完了していないため結果を渡せない場面などで使用できます。

上司: 「さっき頼んだ作業なんだけど完了している？」
自分: 「102」

103 Early Hints

サーバーが最終的なレスポンスを準備する間に、クライアントに必要なリソースを事前に読み込むよう指示します。

上司が先行情報を求めているが、まだ完全な結果を渡せないため現段階でわかっている情報やヒントを渡す場面で使用できます。

上司：「明日のミーティングで何か先に共有できる情報はある？」
自分：「103。〇〇についての調査結果についてまとめました。https://qiita.com/cardene 」

2xx

200 OK

リクエストが成功したことを示します。

「はい」や「Yes」などの肯定的な返答をする場面などで使用できます。

上司：「お願いしていた開発完了している？」
自分：「200」

201 Created

リクエストは成功し、その結果新たなリソースが作成されたことを示します。

新しいプロジェクトやタスクの完了を報告する場面などで使用できます。

上司：「新しいプロジェクトファイルはできた？」
自分：「201」

202 Accepted

リクエストは受理されたが、まだ実行されていないことを示します。

依頼したタスクの進捗を確認する場合に、取り掛かっているがまだ完了していない場面などで使用できます。

上司：「月曜にお願いしていたタスクの進捗どう？」
自分：「202。backlogに進捗まとめています。」

203 Non-Authoritative Information

返されるメタ情報が生成元サーバーからのものと同一ではない場合に使用されます。

情報の正確性を確認する時に、提供された情報が第三者のものから得られたことを伝える場面などで使用できます。

上司：「このデータ、信頼できる？」
自分：「203。https://qiita.com/cardene 」

204 No Content

リクエストに対して送信するコンテンツはないが、ヘッダーは有用であることを示します。

作業の結果を確認する時に、完了したこと以外返す内容がない場面などで使用できます。

上司：「この作業について何か共有事項とかある？」
自分：「204」

205 Reset Content

サーバーがクライアントに対して、リクエストを送信した文書（例：フォーム）をリセットするよう指示することを示します。

作業のリセットを求められた時に、作業をリセットすることを伝える場面などで使用できます。

上司：「この作業リセットしてもう一度行ってくれる？」
自分：「205」

206 Partial Content

クライアントがリソースの一部だけをリクエストした時に使用されます。

作業の一部の進捗を確認する時に、リソースの一部を渡す場面などに使用できます。

上司：「〇〇までの進捗見せてくれる？」
自分：「206。https://qiita.com/cardene 」

207 Multi-Status

複数のステータスコードがあてはまる状況で、複数のリソースに関する情報を伝えます。

複数の作業の状況を確認する時に、各作業のステータスを報告する場面などで使用できます。

上司：「〇〇と〇〇のタスクの状況について教えてくれる？」
自分：「207。backlogにまとめています。」

208 Already Reported

同じコレクション内で既に報告されたリソースを再度リストアップすることを避けるために使用されます。

既に報告済みの状況を再度確認された時に、既に報告されたこと伝える場面などで使用できます。

上司：「この前お願いした〇〇の件どうなってる？」
自分：「208。slackのリンク」

226 IM Used (HTTP Delta encoding)

サーバーがGETリクエストを処理し、結果として返すデータが元のリソースに対して行われた変更を含んでいることを示します。

変更や更新の状況を確認する時に、変更した結果を渡す場面などで使用できます。

上司：「〇〇の最新版ってどこにある？」
自分：「226。https://qiita.com/cardene 」

3xx

300 Multiple Choices

リクエストに対して複数のレスポンスがあることを示し、ユーザーはその中からひとつを選択します。

複数の選択肢を提示している時、その選択肢の中からどれかを選ぶ場面などで使用できます。

上司：「このプロジェクト、どのツールを使って進めるか決めてくれる？」
自分：「300。〇〇にします。」

301 Moved Permanently

リクエストされたリソースのURLが永遠に変更されたことを示し、レスポンスで新しいURLが与えられます。

プロジェクトやリソースの恒久的な変更を伝える場面などで使用できます。

自分：「〇〇のファイル見当たらないのですがどこにありますでしょうか？
上司：「301 https://qiita.com/cardene 」

302 Found

リクエストされたリソースのURIが一時的に変更されたことを示します。

一時的な変更を伝える場面などで使用できます。

自分：「ここのタスクは現在の方法で進めて良いでしょうか？それともこの前お話しされていた方法の方で一旦進めましょうか？」
上司：「302。別の方法で行こう！」

303 See Other

リクエストされたリソースを別のURIでGETリクエストを使用して取得するようクライアントを誘導します。

別の場所にある情報を参照するよう指示する場面などで使用できます。

自分：「この資料の詳細情報はどこにありますか？」
上司：「303。 https://qiita.com/cardene 」

304 Not Modified

レスポンスは変更されていないことを示し、クライアントはキャッシュ済みのレスポンスを使い続けます。

データや情報が更新されていないことを確認する時に、変更がないことを伝える場面などで使用できます。

上司：「この仕様書何か更新があった？」
自分：「304」

307 Temporary Redirect

リクエストされたリソースを別のURIで、元のリクエストと同じメソッドを使用して取得するようクライアントを誘導します。

一時的なリソースの場所変更を伝える場面などで使用できます。

自分：「このリンクの資料が見当たらないのですが、どこにありますでしょうか？」
上司：「「307。https://qiita.com/cardene 」

308 Permanent Redirect

リソースが別のURIへ永続的に移動したことを示します。

リソースの恒久的な場所変更を伝える場面などで使用できます。

自分：「〇〇の資料前会った場所にないのですがどこにありますでしょうか？
上司: 「308。https://qiita.com/cardene 」

4xx

400 Bad Request

クライアントのエラー（不正なリクエスト構文、不正なリクエストメッセージフレーム、不正なリクエストルーティングなど）により、サーバーがリクエストを処理できない場合を示します。

不適切な指示や情報を提供した時に、内容が不正確または不完全であることを伝える場面などで使用できます。

上司：「このデータ、どうなってる？」
自分：「400」

401 Unauthorized

リクエストされたレスポンスを得るために認証が必要であることを示します。

認証が必要な情報を求めた時に、認証が必要であることを伝える場面などで使用できます。

上司：「このファイル、見せてくれ。」
自分：「401。パスワードは こちら です。」

403 Forbidden

認証されていないなどの理由でクライアントにコンテンツのアクセス権がなく、サーバーが適切なレスポンスの返信を拒否していることを示します。

アクセス権のない情報を求めた時に、自分もアクセス権がないことを伝える場面などで使用できます。

上司：「このデータ、見せてくれ。」
自分：「403」

404 Not Found

サーバーがリクエストされたリソースを発見できないことを示します。

存在しないリソースを求められた時に、リソースが見つからないことを伝える場面などで使用できます。

上司：「〇〇のファイルの場所教えて！」
自分：「404」

405 Method Not Allowed

サーバーがリクエストメソッドを理解しているが、無効にされているため使用できないことを示します。

許可されていない操作を依頼した時に、操作が許可されていないことを伝える場面などで使用できます。

上司：「このデータを削除してくれ。」
自分：「405」

406 Not Acceptable

サーバーが与えられた条件に合うコンテンツを見つけられない場合に送信されます。

要求した条件に合わない情報を求められた時に、条件に合わないことを伝える場面などで使用できます。

上司：「csvでデータを提供してくれ。」
自分：「406。jsonでも良いですか？」

407 Proxy Authentication Required

プロキシーサーバーが認証を要求していることを示します。

プロキシーを介したアクセスを要求した時に、プロキシー認証が必要なことを伝える場面などで使用できます。

上司：「この情報にアクセスしてくれ。」
自分：「407」

408 Request Timeout

サーバーが一定時間アイドル状態の接続を終了させたいことを示します。

ちょっと前にお願いされていたタスクがあったが、他のタスクなどで忙しく処理できていない時に返信する場面などで使用できます。

上司：「この前お願いしていたタスクどうなってる？」
自分：「408」

409 Conflict

リクエストがサーバーの現在の状態と矛盾する場合に送信されます。

現在の状態と矛盾する指示を出した時に、矛盾があることを伝える場面などで使用できます。

上司：「このデータを更新してくれ。」
自分：「409。こちら どうしましょうか？」

410 Gone

リクエストされたコンテンツがサーバーから永久に削除されている場合に送信されます。

既に削除されたリソースを求めた時に、永久に削除されたことを伝える場面などで使用できます。

上司：「以前のプロジェクトファイルまだある？」
自分：「410」

411 Length Required

サーバーがContent-Lengthヘッダーフィールドを要求しているが、リクエストで定義されていないためリクエストを拒否したことを示します。

不完全なデータを送信した時に、必要な情報が欠けていることを伝える場面などで使用できます。

上司：「このデータを送信してくれ。」
自分：「411。〇〇の情報いただきたいです！」

412 Precondition Failed

サーバー側で適合しない前提条件が、クライアント側のヘッダーに含まれていることを示します。

要求が前提条件と一致しない時の返答などの場面などで使用できます。

上司：「この条件で作業を進めてくれ。」
自分：「412。〇〇はどうしましょう？」

413 Payload Too Large

リクエストの本体がサーバーで定めている上限を超えていることを示します。

過剰なデータを送信した時に、データが大きすぎることを伝える場面などで使用できます。

上司：「このファイルを送信してくれ。」
自分：「413」

414 URI Too Long

クライアントがリクエストしたURIがサーバーで扱える長さを超えていることを示します。

長すぎるURLを指定した時に、URLが長すぎること伝える場面などで使用できます。

上司：「このURLを使ってくれ。」
自分：「414」

415 Unsupported Media Type

リクエストされたデータのメディア形式をサーバーが対応しておらず、サーバーがリクエストを拒否したことを示します。

対応していないファイル形式を指定した時に、ファイル形式が対応していないこと伝える場面などで使用できます。

上司：「jpgファイルを送信してくれ。」
自分：「415。pngでも良いですか？」

416 Range Not Satisfiable

リクエスト内のRangeヘッダーフィールドで指定された範囲を満たすことができないことを示します。

特定のデータが不適切なことを伝える場面などで使用できます。

上司：「30ページのデータを送って。」
自分：「416。25ページまでしかないです。」

417 Expectation Failed

Expectリクエストヘッダーで指定された内容がサーバー側と適合しないことを示します。

条件が不適切であることを伝える場面などで使用できます。

上司：「この条件でデータを取得できるか？」
自分：「417。〇〇の形式が違うようです。」

418 I'm a teapot

サーバーはティーポットでコーヒーを淹れようとする試みを拒否します。

冗談やありえないことを連絡してきた場合に、その冗談に答える場面などで使用できます。

上司：「ティーポットでコーヒーを淹れてくれ。」
自分：「418」

421 Misdirected Request

リクエストがレスポンスを生成できないサーバーに送られたことを示します。

リクエストが不適切な宛先に送られた時に、リクエストの宛先が間違っていることを伝える場面などで使用できます。

上司：「この情報を取得してくれ。」
自分：「421。〇〇さんですかね？」

422 Unprocessable Content

リクエストは適正ですが、意味が誤っているために従うことができないことを示します。

リンクが間違っているデータなどの送付時に、リンクが間違っていることを伝える場面などで使用できます。

上司：「このデータを〇〇さんに送信してくれ。」
自分：「422。リンクが間違っているようです。」

423 Locked

アクセス中のリソースがロックされていることを示します。

ロックされているリソースにアクセスしようとしていることを伝える場面などで使用できます。

上司：「このファイルを編集してくれ。」
自分：「423」

424 Failed Dependency

前のリクエストが失敗したため、このリクエストも失敗したことを示します。

依頼が以前の失敗に依存していることを伝える場面などで使用できます。

上司： 「このタスクを完了してくれ。」
自分：「424。先に〇〇を進める必要があります。」

425 Too Early (Experimental)

サーバーが繰り返される可能性のあるリクエストを処理するリスクを望まないことを示します。

早すぎるタイミングでリクエストを出していることを伝える場面などで使用できます。

上司：「このデータを送信してくれ。」
自分：「425。ミーティング後の方が良いと思います！」

426 Upgrade Required

サーバーが現在のプロトコルを使用したリクエストの実行を拒否し、別のプロトコルにアップグレードする必要があることを示します。

現在の方法では対応できない要求をした時に、方法のアップグレードが必要であることを伝える場面などで使用できます。

上司：「これを実装してくれ。」
自分：「426。〇〇を使用するように更新する必要があります。」

428 Precondition Required

オリジンサーバーはリクエストが条件付きになることを必要としていることを示します。

要求が前提条件を必要あることを伝える場面などで使用できます。

上司：「この作業を進めてくれ。」
自分：「428。〇〇はどうしますか？」

429 Too Many Requests

ユーザーが一定の時間内に大量のリクエストを送信したことを示します。

短時間で過剰な要求をしていることを伝える場面などで使用できます。

上司：「このタスクを全部今すぐ処理してくれ。」
自分：「429😡」

431 Request Header Fields Too Large

ヘッダーフィールドが大きすぎるため、サーバーがリクエストの処理ができないことを示します。

あまりにも多くの情報を要求された場面などで使用できます。

上司：「〇〇に関するデータ全て送って。」
自分：「431」

451 Unavailable For Legal Reasons

政府によって検閲されたウェブページなど違法なリソースをリクエストしていることを示します。

法的に制限された情報を求めた時に、法的な理由でアクセスできないことを伝える場面などで使用できます。

上司：「この情報とってきて！」
自分：「451」

5xx

500 Internal Server Error

サーバー側で処理方法がわからない事態が発生したことを示します。

予期しない問題が発生したことを報告する場面などで使用できます。

上司：「ミーティング始まっているけどこれそう？」
自分：「500。〇〇対応中なので参加できなさそうです...。」

501 Not Implemented

リクエストメソッドをサーバーが対応しておらず扱えないことを示します。

対応していない機能や手順を求られた時に、要求された機能が実装されていない場面などで使用できます。

上司：「この新しい機能もう触れる？」
自分：「501」

502 Bad Gateway

リクエストの処理に必要なレスポンスを受け取るゲートウェイとして動作するサーバーが無効なレスポンスを受け取ったことを示します。

他のシステムとの連携に問題があることを伝える場面などで使用できます。

上司：「他の部署との連携はどうなっている？」
自分：「502。ダメでした。」

503 Service Unavailable

サーバーがメンテナンスや過負荷でダウンしているため、リクエストを処理する準備ができていないことを示します。

業務が一時的に停止していていることを伝える場面などで使用できます。

上司：「〇〇プロジェクト、今どうなってる？」
自分：「503」

504 Gateway Timeout

ゲートウェイとして動作するサーバーが時間内にレスポンスを得られなかったことを示します。

外部からの返答が遅れている場面などで使用できます。

上司：「パートナー企業の返事はどうなっている？」
自分：「504。まだ返ってきません。」

505 HTTP Version Not Supported

リクエストで使用したHTTPのバージョンにサーバーが対応していないことを示します。

提出されたフォーマットが合わない場面などで使用できます。

上司：「csvフォーマットで資料を提出してくれない？」
自分：「505。csvでも良いですか？」

506 Variant Also Negotiates

サーバーに内部構成エラーがあり適切な応答を生成できないことを示します。

内部設定に問題がある場面などで使用できます。

上司：「このプロジェクトの設定に問題はないか？」
自分：「506。一部設定に問題があります。」

507 Insufficient Storage

サーバーがリクエストを完了させるために必要な表現を保存できなかったことを示します。

資料やデータの保存容量が不足している場面などで使用できます。

上司：「このデータを保存できるか？」
自分：「507。ストレージが不足しています。」

508 Loop Detected

サーバーがリクエストの処理中に無限ループを検出したことを示します。

作業が無限ループに陥っている場面などで使用できます。

上司：「このタスク進展はある？」
自分：「508。ずっと同じエラー対応しています。」

510 Not Extended

サーバーがリクエストを適切に処理するために、追加情報が必要であることを示します。

追加の情報や拡張が必要な場面などで使用できます。

上司：「この提案をもっと具体的にできる？」
自分：「510。特にどこら辺でしょうか？」

511 Network Authentication Required

クライアントがネットワークでアクセスするために認証が必要であることを示します。

ネットワークアクセスに認証が必要な場面などで使用できます。

上司：「このネットワークにアクセスできる？」
自分：「511。ここを確認してください。」

まとめ

いかがだったでしょうか？
個人的にはなかなか面白い提案だったと思っています。
ここまでで述べてきたことをもとに主張したいこととしては、「一生面白いことをしていく」ということです。
よくキャリアプランなどを聞かれることがあると思いますが、自分の場合は明確なものは一切ありません。
ただ面白いことを追求していくという姿勢でいます。
ただ面白いことを追求した結果、これまで様々な経験をさせていただいたのでこれからも面白く楽しくエンジニアとしての生活を謳歌していきます。

最後に

今回はHTTPステータスコードを使用して会話をすることについてまとめてみました。
実際にまとめてみて色々使えそうだなと感じました。
上司・部下の関係だとなかなか使いづらい場合は、エンジニアコミュニティなどで試験的に使ってみても良いかもしれないです。
「このHTTPステータスコードも追加して！」や「このHTTPステータスコードの使用例はこっちの方が良いんじゃない？」、「よりこっちの方が正しそう！」などあればコメントで教えてください🙇‍♂️

普段色々記事を書いているので、よければそちらもみていってください。

参考