JSON の形式化 APIデバッグにおけるPretty-Printerが重要な理由
ミニファイされたJSONは転送効率が良い一方、デバッグが困難です。オンラインのJSONフォーマッターをいつ使用すべきか、フォーマットがどのように一般的なエラーをキャッチするのに役立つか、そして本番環境でなぜプリティプリントを行ってはいけないのかについて学びましょう。
APIエンドポイントにちょうどアクセスしました。レスポンスはターミナルに単一のテキストの壁として表示されます。すべてのキーと値が1つの切れ目のない行に圧縮されています。間違ったフィールドを見つけるには、スキャンして進める必要があります {"id":1,"login":"octocat","node_id":"MDQ6VXNlcjE=","avatar_url":"https://github.com/images/error/octocat_happy.gif"... 目がくらくまで。
これはまさに JSONフォーマッタオンライン (またはその他のフォーマッタ)が解決する問題です。データを変更するのではなく、読み取り不可能な構造を、脳が実際に解析できるものに変換することで解決します。
JSONフォーマットが実際に行うこと
JSONフォーマットは空白の操作です。それ以上でもそれ以下でもありません。フォーマッタはコンパクトで有効なJSON文字列を取得し、改行とインデントを追加して、階層が視覚的に明らかになるようにします。フォーマット前後でデータは同じです。
実例を以下に示します。これは縮小されたGitHubスタイルのユーザーオブジェクトです:
{"id":1,"login":"octocat","node_id":"MDQ6VXNlcjE=","avatar_url":"https://github.com/images/error/octocat_happy.gif","gravatar_id":"","url":"https://api.github.com/users/octocat","html_url":"https://github.com/octocat","type":"User","site_admin":false,"name":"The Octocat","company":"@github","location":"San Francisco, CA","email":null,"public_repos":8,"followers":20,"following":0}
フォーマッタを通して実行した後:
{
"id": 1,
"login": "octocat",
"node_id": "MDQ6VXNlcjE=",
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"gravatar_id": "",
"url": "https://api.github.com/users/octocat",
"html_url": "https://github.com/octocat",
"type": "User",
"site_admin": false,
"name": "The Octocat",
"company": "@github",
"location": "San Francisco, CA",
"email": null,
"public_repos": 8,
"followers": 20,
"following": 0
}
同じデータです。null メールフィールドを2分ではなく2秒以内で見つけることができます。
形式化されたアウトプットがバグをより速くキャッチするのに役立つ方法
ほとんどのJSONパース エラーは短いリストの間違いから発生します:カンマの欠落、最後のアイテムの後の末尾カンマ、かっこの不一致、またはクォートのないキー。フォーマットされたJSONはこれらすべてを一目で明らかにします。
縮小されたJSONの欠落カンマは、500文字の文字列に隣同士に座っている2つの値のように見えます。フォーマットされたアウトプットでは、それは明らかです。4行目と5行目の間に区切り文字がありません。同じロジックが末尾カンマ(PythonのJSONモジュールのような厳密なパーサーの問題)と不一致のかっこに適用されます:各閉じ括弧が正しいインデント付きで独自の行に座っているとき、位置ずれたものはすぐに目立ちます。 json JSONレスポンスのパースエラーを30秒以上かけて位置付けている場合、ほぼ確実に縮小されたアウトプットを見ています。まずそれをフォーマットしてください。
JSONフォーマッタオンライン対 CLI対 エディタ:いつどれを使うか
JSONをフォーマットする主な方法は3つあり、それぞれ異なるトレードオフがあります:
インストールが必要です
| 道具 | 構文検証 | 大きなファイルを処理します | (CLI) |
|---|---|---|---|
jq VS Code | はい | はい | はい |
| はい(組み込み) | はい | はい(制限付き) | オンラインツール(例:IO Tools) |
| ツールに依存します | いいえ | はい | はコマンドラインワークの金標準です。 |
jq は有効なJSONを即座にフォーマットし、構造をフィルター、変換、クエリできます。ターミナルで真摯なAPIワークを行う場合、 cat response.json | jq . インストールする価値があります。 jq JSONをネイティブにフォーマットします。右クリックして[ドキュメントのフォーマット]をクリックするだけです。組み込みエディタは、入力時に構文エラーをインラインで強調表示します。これは、生のAPIアウトプットを検査するのではなく、設定ファイルを編集する場合に便利です。
はい(組み込み) (例:
あ JSONフォーマッタオンライン IO Tools JSONフォーマッタ )は、ブラウザを離れたくない場合、通常のツールのない機械を使用している場合、またはフォーマットされたアウトプットを他の人と共有する必要がある場合の最速オプションです。貼り付け、フォーマット、完了です。インストールなし、セットアップなし、コンテキスト切り替えなし。 JSONフォーマッタ対 JSONバリデータ:同じものではありません
これらの用語は交換可能に使用されていますが、それらは異なるジョブを実行します。
フォーマッタ
あ はJSONを読みやすくします。プロセス中に明らかな構文エラーをフラグします可能性がありますが、その仕事はプレゼンテーション(コンパクトな文字列をインデントされた構造に変える)です。 バリデータ
あ は、JSONがスキーマまたはJSON仕様に適合しているかどうかを確認します。値が間違った型であるかどうか、必須フィールドが欠落しているかどうか、または構造がAPIが期待するものと一致しないかどうかを示します。JSONはエラーなくパースされるが、ランタイムで動作が正しくない場合、フォーマットは役に立ちません。バリデータが必要です。 IO Toolsは別の
JSONバリデータ をこの理由で提供しています。一般的なワークフロー:最初にフォーマットしてデータを読みやすくし、構造自体が疑問の場合は検証します。 本番環境でのプリティプリントは避けてください
APIを構築している人向けの注釈:フォーマットされたJSONは人間用であり、機械用ではありません。プリティプリントはバイトを追加します。インデントスペース、改行。これはすべてのレスポンスペイロードを膨らませます。トラフィックの多いエンドポイントでは、そのオーバーヘッドは急速に複合します。
本番APIレスポンスは縮小状態に保ちます。デバッグ、文書化、または手動でアウトプットを読むときのみフォーマッタを使用します。これはマイクロ最適化ではありません。不要な空白を数百万のリクエストに渡して出荷しないだけです。
縮小されたJSONは転送効率が良く、読むのがほぼ不可能です。APIで作業するすべての開発者は、生のレスポンスを見つめることに時間を費やします。フォーマットされたアウトプットはその時間を短く、エラーが少なくします。あなたが何に手を伸ばすかどうかに関わらず
結論
、エディタの組み込みフォーマッタ、または jqに依存するポイントは、手で圧縮されたJSONを読むのをやめることです。 JSONフォーマッタオンライン depends on your context. The point is to stop reading compressed JSON by hand.
