HTTPとは
HTTPは、Webのクライアントとサーバーが要求と応答を交換するためのアプリケーション層プロトコルです。正式名称はHypertext Transfer Protocol（ハイパーテキスト・トランスファー・プロトコル）で、エイチティーティーピーと読みます。
ブラウザーが「どの資源に、どの操作をしたいか」を要求として送り、サーバーが処理結果と資源の表現を応答として返します。HTMLだけでなく、画像、動画、APIのJSON、ファイル送受信にも同じ意味体系を使います。
HTTPが定める中心はWeb上の意味であり、画面そのものでも、一本の特定通信路でもありません。同じメソッド、ヘッダー、状態コードを、HTTP/1.1・HTTP/2・HTTP/3が異なる転送形式で運びます。
要求と応答は、意味の異なる部品からできている
GET、POST、PUT、DELETEなどが要求の操作意味を示す
URIから導く対象を、要求ターゲットとしてサーバーへ伝える
形式、認証、キャッシュ条件、内容長などを名前と値で渡す
フォーム、JSON、ファイル、返す表現などを必要な場合に収める
状態コードが成功、転送、利用者側・サーバー側の問題を分類する
同じ資源をHTML、JSON、画像など目的に合う形式で表せる
資源と表現を分けると、同じURLから異なる形式を返せる
URLやURIが指すものをresource（リソース／資源）、その時点の状態を通信へ載せられる形にしたものをrepresentation（レプリゼンテーション／表現）と呼びます。商品情報という一つの資源を、ブラウザーにはHTML、アプリにはJSONで表すことができます。
AcceptやAccept-Languageなどの要求フィールドを使うcontent negotiation（コンテント・ネゴシエーション／内容交渉）では、同じURIへ複数表現を用意します。キャッシュが取り違えないよう、応答のVaryフィールドで選択に使った要求項目を示します。
メソッドの安全性と冪等性は、再試行できる条件を考える手掛かりになる
safe（セーフ／安全）なメソッドは、利用者がサーバー状態の変更を求めない読み取り用途です。GETやHEADが該当しますが、アクセスログや課金計測のような副作用が一切ないという意味ではありません。
idempotent（アイデンポテント／冪等）は、同じ要求を一回実行した場合と複数回実行した場合で、意図したサーバー上の効果が同じになる性質です。PUTやDELETEは冪等として定義されます。通信が切れたとき自動再試行してよいかは、メソッド名だけでなく、操作内容とアプリの重複防止まで含めて判断します。
ステートレスとは、各要求を解釈できる情報を要求側が持つこと
HTTPはstateless（ステートレス）な要求・応答プロトコルです。サーバーが利用者情報を保存してはいけないという意味ではなく、各要求を以前の要求順序へ暗黙に依存させず、処理に必要な文脈を要求へ含めます。
ログイン状態はCookie、Authorizationフィールド、サーバー側セッションなどでHTTPの上に構成します。同じTCP接続を再利用しても、HTTPの意味上、二つ目の要求が一つ目の画面状態を自動的に引き継ぐわけではありません。
キャッシュは再利用条件を守り、古い表現かを検証する
ブラウザーや中継キャッシュは、Cache-Control、Expires、Dateなどから応答を再利用できる期間と条件を判断します。期限切れ後も、ETagとIf-None-Match、Last-ModifiedとIf-Modified-Sinceなどの条件付き要求で、内容を再送せず変更有無だけを確認できます。
認証情報や個人別応答を誤共有しないよう、プライベート、no-store、Varyなどを目的に合わせます。プロキシ、ゲートウェイ、CDNが途中に入るため、接続相手と最終的な生成元が常に同一とは限りません。
HTTPだけでは、盗聴防止も接続先の本人確認も行わない
HTTPスキームの通信を平文で運べば、途中で内容を読まれたり書き換えられたりする可能性があります。HTTPの状態コードやチェック機能は暗号学的な完全性を提供しません。Webでは通常、HTTPSとしてTLSで保護します。
HTTPの処理成功と、業務処理の成功も別です。200番台でも本文に詳細な失敗があるAPI、202で受け付けだけ完了する処理があります。状態コード、応答フィールド、アプリ固有の結果を組み合わせて読みます。
仕様の確認資料：RFC 9110「HTTP Semantics」、RFC 9111「HTTP Caching」、RFC 9112「HTTP/1.1」