HTTPとは何ですか？メソッド、メッセージ、ステータスコード、およびキャッシング

はじめに

HTTPはウェブにリソースを識別し、表現を交換するための共有語彙を提供するアプリケーション層プロトコルです。ブラウザはドキュメントをリクエストし、APIクライアントはJSONを送信し、クローラーはHTMLを取得できます。なぜなら、各当事者は同じメソッド、フィールド、ステータスコード、およびメッセージ意味を理解しているからです。

HTTPは固定されたアプリケーションデータモデルを定義していません。リクエストが意図を示す方法と、レスポンスが結果を説明する方法を定義しています。同じ意味はHTTP/1.1、HTTP/2、HTTP/3にわたって生き延びますが、それらのバージョンはメッセージを異なる方法でエンコードし、転送します。

リソース、表現、そしてURI

HTTPはURIによって識別されたリソースで動作します。製品記録、画像、検索結果、およびジョブステータスはそれぞれリソースになり得ます。返されたバイトは、そのリクエストに選ばれた表現であり、HTML、JSON、画像、またはリクエストされた言語での圧縮コンテンツである可能性があります。

この区別は重要です。なぜなら、1つのURIには複数の表現があるからです。リクエストフィールド、例えばAcceptやAccept-Languageはクライアントの好みを説明し、レスポンスフィールド、例えばContent-TypeやContent-Encodingは何が送られたかを説明します。 RFC 9110はHTTPの意味を定義します 現在のバージョンで共有されています。

リクエストの構成

リクエストにはメソッド、ターゲット、フィールド、および時折コンテンツが含まれます。GETは表現を要求します。HEADはレスポンスコンテンツなしで同じメタデータを要求します。POSTは処理のための情報を提供します。PUTはターゲットリソースの置き換えを要求し、DELETEはサーバーに関連付けを削除するよう要請します。

メソッド名は単なるルーティングラベルではありません。安全性と冪等性はキャッシング、自動ツール、および不確実なネットワークの結果からクライアントが回復する方法に影響を与えます。サーバーはアプリケーション特有の動作を公開することがありますが、受け入れるメソッドの標準化された意味を保持するべきです。

レスポンスの構成

レスポンスにはステータスコード、フィールド、およびオプションのコンテンツが含まれます。2xxコードは成功した処理を報告し、3xxはクライアントを他の場所またはキャッシュ状態に誘導し、4xxはリクエストに問題があったことを報告し、5xxはサーバーが有効なリクエストを完了できなかったことを報告します。

ヘッダーは選択された表現、認証チャレンジ、キャッシュポリシー、バリデーター、範囲、クッキー、および中間者に関するメタデータを運びます。レスポンスボディは保証されません：HEAD、204、および304のレスポンスには特別なコンテンツルールがあり、エラーレスポンスはアプリケーション定義の形式で有用な診断情報を持つ場合があります。

ステートレスはメモリレスアプリケーションを意味しない

HTTPはステートレスです。各リクエストは、前のリクエストからのプロトコルレベルの会話状態なしに理解できます。アプリケーションは依然としてクッキー、認証クレデンシャル、サーバー側のセッション、データベースレコード、およびトークンを介して状態を維持します。

この分離によりプロトコルは一般的になります。ショッピングカートは持続できますが、各HTTPリクエストはルーティングと処理に十分に自己記述的です。デザイナーはアプリケーション状態と接続状態を区別し、同じネットワーク接続が同じ認証されたユーザーを意味するとは限らないと仮定することを避けるべきです。

キャッシングと条件付きリクエスト

キャッシュは、メソッド、ステータス、鮮度、およびキャッシュ制御ルールが許可される場合に、保存されたレスポンスを再利用できます。鮮度はオリジンに連絡することを避けます。バリデーションにより、キャッシュは保存された表現が依然として最新かどうかを、エンティティタグや修正日を条件付きリクエストに送信することで尋ねることができます。

成功したバリデーションは308なしで再び表現を転送することなく304を返すことができます。正しいキャッシュキーはターゲットURIおよびVaryで名付けられた選択されたリクエストフィールドを考慮する必要があります。 HTTPキャッシング仕様 はこれらの制御を定義し、指示が適切に設定された場合に私的なレスポンスがユーザー間で漏れないようにします。

接続、プロキシ、およびバージョン

HTTPメッセージはオリジンに到達する前に、プロキシ、ゲートウェイ、キャッシュ、およびコンテンツ配信ネットワークを通過することがあります。各中間者は、メッセージをプロトコルのルール内でルーティング、認証、変換、または保存できます。エンドツーエンドのフィールドはリソースの交換を説明し、接続固有の処理はプロトコルバージョンに依存します。

HTTP/1.1はバイトストリーム上でテキストメッセージ構文を使用します。HTTP/2は同じ意味をバイナリフレームと多重ストリームにマッピングします。HTTP/3はそれらをQUICにマッピングします。 MDNのHTTP概要 は同じクライアント、サーバー、および中間者モデルのブラウザ向けのビューを提供します。

HTTPとは？ メソッド、メッセージ、ステータスコード、キャッシュ検証計画

HTTPはリクエスト-レスポンスプロトコルです。クライアントはリクエストを送信し、サーバーはレスポンスを返します。その主張が完全な生産経路で検証されることを確認してください。小さな代表的な交換から始め、クライアントとエッジで交渉された動作を記録し、アプリケーションが期待するフィールド、フレーム、またはイベントを同じゲートウェイ、プロキシ、証明書終了点、および実際のトラフィックで使用されるネットワークポリシーを通じて受信することを確認します。

最初の設計の仮定を失敗の演習に変えます：安定したURIでリソースに名前を付けます。そして、2番目の仮定に関するリソース圧力を検査します：定義されたセマンティクスに基づいてメソッドを選択します。正確な実装は、文書化された制限内で失敗し、接続とバッファの状態を解放し、結果を説明する痕跡を残し、資格情報やプライベートペイロードを露出することなく残すべきです。

WebナビゲーションとマシンAPIは設計の異なる部分を演習するため、互換性テストには関連する交通形態の両方を含める必要があります。現在のブラウザ、非ブラウザクライアント、遅いネットワーク経路、およびサポートされている最も古い中間者を追加してください。優先パスとそのフォールバックのバージョン選択、接続寿命、メッセージまたはレスポンスの寿命、キューの深さ、終了理由を記録します。

テスト中にセマンティクスとトランスポートを別のレイヤーとしてレビューします。成功した接続は、アプリケーションが順序、承認、キャンセル、キャッシュ、リプレイ、または状態回復を正しく処理したことを証明するものではありません。同様に、アプリケーションエラーは交渉されたプロトコルが失敗したことを証明しません。リソース、ユーザー範囲、論理操作、および接続識別子で観察をタグ付けし、次に各エンドポイントが何が起こったと考えたかを比較します。この分離により、容量仕事がより有用になります：チームはレイテンシが接続設定、ネットワーク配信、キューイング、アプリケーション処理、シリアル化、または遅い受信者から来たのかを確認できます。プライベートコンテンツを定期的なテレメトリーから除外しつつ、決定を再現するのに十分なタイミングと成果データを保持します。

HTTPとは？ メソッド、メッセージ、ステータスコード、キャッシュが実際にどのように現れるか

HTTPとは？ メソッド、メッセージ、ステータスコード、キャッシュの生産チェックリスト

• 安定したURIでリソースに名前を付けます。 このポイントを文書化された受け入れテストに変えて、レビュアーが意図された動作を意図しない実装の詳細から区別できるようにします。
• 定義されたセマンティクスに基づいてメソッドを選択します。 設定を所有するコンポーネントの名前と、その観察された動作が変化したときに応答する人物またはチームの名前を付けます。
• 実際の結果を説明するステータスコードを返します。 関連する信号をログやトレースにキャプチャし、その後、信号が実際の経路のすべてのプロキシ、ゲートウェイ、およびサービス境界を生き残ることを確認します。
• すべての表現についてContent-Typeを設定します。 通常のケース、遅いピア、閉じた接続、過剰な入力、およびバージョンまたは能力の不一致で決定をテストします。
• 接続のアイデンティティから認証状態を分離します。 安全なデフォルトと例外を許可する正確な条件を文書化します；隠れた例外は今後の変更時に相互運用性の問題になります。
• センシティブなレスポンスに対してキャッシュ動作を明示的に定義します。 ローカルの単体テストやサーバー側の設定画面だけに依存せず、代表的なブラウザやクライアントからこの動作をチェックします。
• 大規模または頻繁にチェックされるリソースにはバリデーターを使用します。 有限のリソース制限を設定し、その結果としての拒否をオペレーターと呼び出しアプリケーションの両方に明示的にします。
• 中間者を介してリクエスト識別子をログに記録します。 クライアント、エッジ、アプリケーション、および任意の非同期ワーカー間で1つの論理交換を相関させるために十分な識別子を保持します。
• クライアントが見えるエラーを一貫した形式で保持します。 トラフィック形状の変更後に選択をレビューします。接続数、ペイロードサイズ、およびメッセージ頻度が正しい設計を変更する可能性があるためです。
• プロトコルバージョンにわたるテストの動作を確認します。 フォールバックパスが観察可能でテストされていることを維持し、互換性が静かに機能しなくなった古いパスに依存しないようにします。

結論

HTTPはリクエスト-レスポンスプロトコルです。クライアントがリクエストを送信し、サーバーがレスポンスを返します。HTTPの意味は各ワイヤーバージョンよりも長く存続します。フレーミングはバージョンごとに変化し、メソッドとレスポンスの意味は馴染みのあるままです。これら2つの事実を明示的な制限、観察可能な状態、および構成から仮定されるのではなく、代表的なクライアントによってテストされたフォールバックと共に適用します。

参考文献

• ScrapelessユニバーサルスクレイピングAPIのドキュメント
• ScrapelessユニバーサルスクレイピングAPIの製品概要
• Scrapeless C++ HTTPスクレイピングガイド