JSON to Go: 最初の試行でアンマーシャルする構造体

生成された形状

コンバーターは、各 JSON オブジェクトを構造体に、各配列をスライスに変換し、値ごとに Go タイプを推論します。ネストされたオブジェクトは匿名 BLOB ではなく名前付き型になり、デコード コードの署名を読み取り可能な状態に保ちます。

                type Container struct {
  Name  string `json:"name"`
  Image string `json:"image"`
  Ports []struct {
    ContainerPort int `json:"containerPort"`
  } `json:"ports"`
}
              

`json` タグは重要な部分です。 Go のデコーダはフィールド名を照合するときに大文字と小文字を区別しませんが、`containerPort`​​ と `ContainerPort` はタグなしでは整列しません。また、有効な Go 識別子ではないキー (たとえば、`app.kubernetes.io/name`) はタグなしではまったく照合できません。

数値、NULL、および 2 つの古典的な罠

• 数値 — 推論では整数値に対して `int` が生成されますが、JSON には整数型がありません。今日 `3` であるフィールドは明日には `3.5` になる可能性があるため、ID とお金はニーズに応じて `float64`、`string`、または `json.Number` として使用する方が安全です。
• Null — `null` の可能性があるキーはポインタ (`*string`) である必要があり、「不在」と「空」を区別できます。
• タイムスタンプ — RFC 3339 文字列は `time.Time` にきれいにデコードされます。 Unix エポック番号はそうではないため、それらを `int64` として保持し、明示的に変換します。
• 不明なフィールド — `json.Decoder` はデフォルトで追加情報を無視します。大きな音で失敗したい場合は、`DisallowUnknownFields` を使用します。

可能であれば、2 つまたは 3 つの応答から生成します。時々欠落しているフィールドがポインターとなり、その決定は記憶よりも証拠に基づいて行う方がはるかに簡単です。

構造体から動作するコードまで

構造体を配置すると、デコードは 3 行で、コンパイラーはそこからアクセス パスを強制します。一般的なパターンは、生成された構造体をデコードしてから、アプリケーションに波及することなく JSON の形状を変更できるように、ドメイン タイプにマップすることです。生成されたファイルに元のエンドポイントをタグ付けし、手動で編集するのではなく、応答が変化したときに再生成します。手動で編集された生成コードは、後で誰も再生成することを敢えてしないバージョンです。

ローカルで生成

Go 構造体を生成する価値のあるペイロードは通常、実際の API レスポンスであり、実際のレスポンスにはトークンと顧客データが含まれます。ブラウザベースの JSON to Go 変換では、ペイロードがタブに保持されるため、アップロードや保持に関する質問はありません。これにより、運用データからの生成がポリシーの例外ではなく通常のステップになります。