仮のHTTP応答ビルダー
ガイド
仮のHTTP応答ビルダー
構造的に正しいHTTP応答メッセージを秒単位で構築します。ステータスコードを選択し、ボディタイプを選び、ヘッダーを追加し、ツールは準備された応答文字列をCRLFで区切って出力し、テストフィクスチャ、統合モック、APIドキュメント、クライアントへの応答再現に最適です。
使用方法
- を選択します HTTPバージョン (HTTP/1.1 にデフォルト) および ステータスコード グループ選択器から選択する — たとえば
200 OK,404 Not Found、 または503 Service Unavailable. - (オプション) 理由表現を上書きする 理由表現 理由表現を非標準のテキストとして必要に応じて上書きします。
- [ブラウザのchrome]を選択し、 ボディタイプ (テキスト、JSON、XML、HTML、フォーム、またはなし) およびボディを入力または貼り付けます。
- トグル 自動コンテンツタイプ, 自動コンテンツ長と、 日付 サーバーが応答するようにヘッダーを設定します。
- 追加のヘッダーを追加 — 一般的なヘッダー(キャッシュ制御、ETag、Set-Cookie、CORS、レート制限ヘッダー)から選択するか、カスタム名/値ペアを入力します。
- 完全な応答をコピー、ヘッダーのみをコピー、または
.httpファイルをダウンロードして、RESTクライアント、フィクスチャ、または再現ツールで使用します。
機能
- グループステータスコード選択器 — 1xxから5xxのコードをクラスごとに整理し、それぞれに標準的な理由表現を提供しています。
- ボディタイプ選択器 — マッチするコンテンツタイプ(application/json、text/html、application/xml、application/x-www-form-urlencoded、text/plain)を自動で埋め込み、ヘッダーとペイロードを同期させます。
- 自動コンテンツ長 — UTF-8エンコードを使用してバイト(文字数ではなく)をカウントし、実際のサーバーが値を計算する方法に一致します。
- IMF-fixdate 日付ヘッダー — 現在の瞬間の標準適合タイムスタンプ(例:
Sun, 06 Nov 1994 08:49:37 GMT)を生成します。 - 一般的な応答ヘッダー — キャッシュ制御、ETag、Expires、Last-Modified、Location、Server、Set-Cookie、Vary、WWW-Authenticate、Access-Control-Allow-Origin、X-RateLimit、およびX-Powered-Byのワンクリックプリセットを提供します。
- – ヘッダー名/値ペアを追加 — 任意の名前/値ペアを追加し、組み立てられた応答のライブプレビューを表示します。
- 2つの出力ビュー — 完全応答(ステータス行+ヘッダー+空白行+ボディ)とヘッダーのみ。どちらかをコピー、または完全応答を
response.http. - 規格適合の行終端 — 行間でCRLF(
\r\n)を使用し、RFC 9112で規定された行終端です。 - リアルタイム更新 — すべての変更が即座に出力が再計算され、提出ボタンは必要ありません。
- ブラウザ内で完全に動作 — どのデータもあなたのマシンに残り、バックエンドは関与しません。
一般的な使用例
- ユニットおよび統合テストフィクスチャ — 出力文字列を、
requests-mock,nock、MSW、WireMock、または任意のHTTPレコーダーに貼り付けます。 - — curl例は、すべてのドキュメントフォーマットです。生成されたコマンドをREADME、Notionページ、Confluenceドキュメントに貼り付けます。どの読者も、言語やスタックに関係なく、すぐに実行できます。 — OpenAPIの例や開発者ドキュメントに、正確な応答の形状(ヘッダー付き)を表示します。
- クライアントデバッグ — 実サーバーを立ち上げずに、まれなサーバー応答(レート制限、部分コンテンツ、リダイレクト)を再現できます。
- HTTPの教育 — 応答メッセージのオンザワイヤー形式(ステータス行、ヘッダー、空白行、ボディ)を可視化します。
- 手動再現 — 応答を
nc -lまたは類似のリスナーにパイプし、クライアントがどのように反応するかをテストします。
よくある質問
-
HTTP/1.1応答メッセージの構造は?
HTTP/1.1応答は、ステータス行、ゼロまたは複数のヘッダー、空白行、およびオプションのメッセージボディから構成されています。ステータス行は、HTTPバージョン、3桁のステータスコード、およびスペースで区切られた理由表現です。すべての行はCRLF(キャリッジリターン+ラインフィード)で終了されます。最後のヘッダーの後にある空白CRLFはボディの開始を示します。この形式はRFC 9112(RFC 7230の継承)で定義されています。
-
コンテンツ長は、バイトか文字を測定しますか?
コンテンツ長はメッセージボディのオクテット(バイト)長であり、文字ではありません。ASCIIテキストでは両方の値が一致しますが、UTF-8エンコードで非ASCII文字を含む場合、値は異なる——1つのエモジーやアクセント文字は通常2~4バイトを使用します。コンテンツ長を文字数から計算することは、HTTPの最も一般的なバグの一つであり、クライアントはボディを切り詰めたり、欠落したバイトを待つためにブロックされます。
-
301と302のリダイレクトの違いは?
両方の応答には新しいURLを指すLocationヘッダーが含まれていますが、意味は異なります。301 Moved Permanentlyは、クライアントおよび検索エンジンにリソースが永久に移動したことを示し、キャッシュやリンクリワイタが元のURLを置き換える可能性があります。302 Found(元々は'Moved Temporarily')は一時的なリダイレクトを示し、将来は元のURLを使用すべきです。現代のメソッドを保持するリダイレクトでは、308(永久)および307(一時)が301および302よりも好まれます。
-
HTTP/2はステータス行と理由表現を使用していますか?
HTTP/2は数値ステータスコードを維持していますが、テキスト理由表現を完全に削除しています。ステータスは偽ヘッダー(:status: 200)として提供され、プロトコルはテキストではなくバイナリでフレーム化されています。理由表現はHTTP/1.xにのみ存在し、常に情報的なものであり、クライアントはステータスコードに反応しなければなりません。
-
HTTPはCRLFを使用する理由は?
HTTPは1980年代に定義された古いインターネットテキストプロトコル(SMTP、NNTP、FTP)から継承した行終了規則を持ち、すべてがCRLF(\r\n)を標準的な終了行として使用しています。RFC 9112の文法では、開始行、ヘッダー項目、およびボディ前の空行の間でCRLFが必須です。多くのサーバーはLFだけを許容していますが、厳密なパーサーおよびプロキシは、キャリッジリターンを省略した応答を拒否する可能性があります。
恵 スコアボードが到着しました!
スコアボード ゲームを追跡する楽しい方法です。すべてのデータはブラウザに保存されます。さらに多くの機能がまもなく登場します!
