例から始める
オブジェクト、配列、文字列、数値は対応する type にマップされます。入れ子オブジェクトはできるだけ properties に展開します。
空配列で要素サンプルがないと items の型が不正確なことがあります。実要素を1件足してから推論してください。
JSON Schema 検証
ローカル処理 次の方法でも #data={"name":"Ada"} または #url=... データを流し込めます。読み取り後はアドレスバーから削除されます。
サンプル JSON から JSON Schema を推論します。先に実レスポンスがあり、あとから API 文書を足す、検証器の出発点にする、といった用途に向いています。推論結果の必須項目と列挙は人手で確認してください。ツールが見るのは「この例にあるもの」だけで、「業務上必須なもの」は見えません。
下書きとして使う
自動推論では「このフィールドが必須か」は分かりません。required は自分で直してください。任意フィールド、列挙、format（email、uri）も人手で足します。
生成後は ajv などのツールで CI を回す方が、口頭の取り決めだけより安定します。
ローカル生成
サンプルデータはアップロードしません。本番サンプルを使うときも、先にマスキングすることを推奨します。
出力には $schema 宣言が含まれ、他ツールがバージョンを識別しやすくなります。
例
{
"id": 1001,
"name": "Ada",
"active": true
}{
"type": "object",
"properties": {
"id": { "type": "number" },
"name": { "type": "string" },
"active": { "type": "boolean" }
}
}別の JSON の検証に使えますか？
このページはサンプルから Schema を生成することが主眼です。生成結果はバックエンドや CI の ajv などに渡して検証してください。
入れ子と配列は？
できるだけ下まで推論します。空配列で要素サンプルがないと item 型が不正確なことがあります。
GraphQL ページとの使い分けは？
REST / JSON 文書は Schema、GraphQL サービスは型推論ページです。
format: email は付きますか？
型推論が中心です。メールなどの形式は業務に合わせて Schema へ足してください。
おすすめの手順
- フィールドができるだけ揃った成功レスポンスのサンプルを用意します。
- Schema を生成し、type と properties が妥当か確認します。
- required、enum、additionalProperties などの制約を手で足します。
- Mock / CI で後続レスポンスを検証し、Diff と合わせてバージョンレビューします。
1つの例では完全な契約は出ません。複数サンプルで突き合わせたうえで Schema を締めてください。