開発者ツール · JSON フォーマッタおよびバリデータ
縮小された API 応答の読み取り: 目を細めて表示するよりもきれいに表示する理由
· なぜそれが重要なのか
json 開発者ワークフロー 検証
縮小された JSON はマシン用です。この投稿では、サーバーが空白を削除する理由、単一行に対してデバッグするときに失われるもの、およびフォーマットによってペイロードが実際に推論できるものにどのように変わるのかについて説明します。
1 行に 30 キロバイト
1 行に 30 キロバイト — ネットワーク パネルからの応答本文とその中に見つからないフィールド。検索によりキーが見つかる可能性がありますが、その親オブジェクト、隣接するレコード、または配列境界に関するコンテキストはほとんど得られません。また、水平スキャンにより、繰り返されるプロパティ名が区別できなくなります。これは、ページ分割された API ペイロードで一般的です。
書式設定により、ドキュメントが解析され、再シリアル化されます。構造を明らかにしますが、数字のスペル、エスケープ、空白を正規化できます。このパネルには、ルート タイプ、キーまたは項目数、深さ、ノード数を含む形状の概要もレポートされるため、外観だけよりも結果を確認しやすくなります。語彙の忠実度が重要な場合、特に大きな数値、指数表記、エスケープされたテキストに関しては、生の応答を保存します。
サーバーが縮小する理由 — 帯域幅、圧縮インタラクション、デフォルトのシリアライザー設定、そしてそれらが人間の読者にとって役に立たない理由
サーバーが縮小する理由 - 帯域幅、圧縮インタラクション、およびデフォルトのシリアライザー設定、そしてそれらが人間の読者にはなぜ役に立たないのか。インデントを削除すると、非圧縮バイト数が減り、装飾的な空白を生成する CPU の消費が回避されます。汎用圧縮ではすでに繰り返しスペースが効率的に圧縮されているため、転送される保存量は生の差分よりも小さくなる可能性がありますが、コンパクトな出力は従来どおりです。
マシンは視覚的な配置ではなくトークンを消費し、クライアントは通常、本体を即座にデータ構造に解析します。人間が 1 つの応答を調査する場合は、反対の要件があります。つまり、安定した改行とインデントによって所有権とネストが明らかになります。運用エンドポイントに詳細な出力を送信するよう要求するのではなく、キャプチャしたコピーを診断用にそのまま出力します。これにより、インシデント中のキャッシュ、応答サイズ、サーバーの動作が変化する可能性があります。
フォーマット後に表示される構造
書式設定後に表示される構造 — ネストの深さ、配列の長さ、空のオブジェクト、最後に隠れていた null。インデントは、`status` が応答、項目、または埋め込み所有者のいずれに属しているかを示します。別々の行は、繰り返されるレコードを公開し、解析された意味を変えることなく、設定されたオブジェクトの中で唯一の `{}` を視覚的に明確にします。
形状の概要は別のチェックを提供します。項目がゼロの配列ルートは、空の `items` 配列を含むオブジェクトとは異なるストーリーを伝えますが、最大の深さでは予期せぬラップされた結果が公開される可能性があります。書式設定により、括弧が予想されるコンテナを閉じるかどうかも明確になります。エディターで折りたたみを使用して、無関係なブランチを折りたたんで、疑わしい値へのパスを表示したままにします。
実際のバグを特定する
実際のバグを特定します。数値が予期される文字列、欠落しているキーと null 値、および単一の要素を持つ配列です。きれいに印刷すると、引用符とリテラルによって型が読みやすくなります。`"0"`、`0`、`false`、`null` は 4 つの異なる値であり、コンパクトなログでは急いで確認する際に不鮮明になる可能性があります。
構造では、不在と明示的な空虚も区別されます。 `nextCursor` が欠落している場合は、サーバーがページ分割メタデータを省略していることを意味する可能性があり、`"nextCursor":null` が意図的に最終ページにマークを付けている可能性があります。空の `items` 配列は、クライアント フォールバック ロジックを引き起こす欠落した `items` プロパティとは異なります。書式設定によりこれらの区別が明らかになりますが、どの形式が正しいかは API コントラクトによって決まります。
実用的な例: ページ分割された応答
うまくいった例: ページ分割された応答 — フォーマットし、次のページのカーソルを見つけ、項目配列が空であることに気づきます。 `{"items":[],"page":{"next":"abc","count":0}}` などのコンパクトなペイロードは有効ですが、そのカーソルとカウントはレコードがないため競合します。インデントは、ページネーションのメタデータを結果データとは別にグループ化します。
このビューは具体的な質問を示唆しています。フィルターはカーソルが計算された後にすべての項目を削除しましたか、`count` はページローカルですかそれとも全体ですか、次のカーソルは空のページに存在する必要がありますか?フォーマッタはそれらに答えることはできませんが、1 つの不透明な行をフィールドに変換し、リクエスト パラメータやドキュメントと照合してチェックできるようにします。証拠として元の応答ヘッダーとステータス ヘッダーを保存してください。
2 つの応答の比較
2 つの応答を比較します。両方を同じインデントで書式設定して、テキスト比較パネルで実際の違いのみを強調表示します。一貫したレイアウトにより、1 つのペイロードのコンパクトなシリアル化によってインデントされたコピーに対するドキュメント全体の差分が生成されることがなくなります。変更された値、挿入されたレコード、欠落しているキーが、読み取り不能な文字ストリームをシフトするのではなく、ローカライズされた行を占有します。
結論を出す前に揮発性フィールドを制御します。ビジネス データが安定している場合でも、リクエスト ID、タイムスタンプ、署名、および順序付けされていないコレクションがテキスト比較の大半を占める可能性があります。メンバーの順序が保持する必要がある証拠である場合は、キーを安易に並べ替えないでください。また、配列の順序はデータであることを覚えておいてください。順序は契約によって無関係であるがシリアル化が異なる場合は、構造を意識した比較が推奨されます。
これでカバーされない内容
これでカバーされないもの — 圧縮またはエンコードされた本体のデコード、およびプロトコル バッファーなどのバイナリ形式の検査。 Base64、gzip バイト、または暗号化されたエンベロープとして表示される本文は、まずそのコンテンツのエンコードを知った上でデコードする必要があります。これらの文字を JSON パーサーに渡すと、基礎となるメッセージについて何も示さない構文エラーが生成されます。
Pretty-printing では、OpenAPI スキーマの検証、サーバー ステータス コードの説明、クライアントの逆シリアル化で同じ型が使用されていることの証明も行われません。切り捨てられたネットワーク キャプチャを復元したり、損失のある JavaScript 解析後に正確な数のトークンを保存したりすることはできません。バイナリ ペイロードにはプロトコル固有のツールを使用し、ヘッダー、リクエスト コンテキスト、生のバイトを人間が判読できるレンダリングとともに保持します。
要点: 最初にフォーマットしてからデバッグする
要点: 最初にフォーマットし、次にデバッグします。理論を形成する前に、フォーマッタのインデントの選択を使用してペイロードの階層を公開します。関連するブランチを見つけて、値のタイプを確認し、欠落、NULL、および空の状態を区別します。既知の良好なサンプルが存在する場合、1 つのレイアウトで応答を比較します。その一方で、詳細の再シリアル化が正規化される可能性があるため、生の入力を保持します。
読み取り可能 JSON により視覚的な労力が軽減されます。 API コントラクトに代わるものではありません。疑わしいフィールドが表示された後、ページネーションの定義、スキーマ要件、ステータス ヘッダー、およびリクエスト パラメーターを確認してください。 ToolAcre はこの解析と書式設定をブラウザーで実行するため、提供されたドキュメントは ToolAcre アプリケーション サーバーにポストされませんが、機密キャプチャはポリシーに従って最小化する必要があります。