JSON Schemaが確かめるのは書いた規則だけ
読めるJSONでもリクエストに適しているとは限りません。スキーマは期待するデータを記述しますが、書いていない条件や外部の事実までは確認できません。
項目の有無と値の型は別の判断
propertiesに書くと、その項目がある場合の条件になります。それだけでは必須ではありません。必須にするにはrequiredへ入れます。
数値3と文字列"3"は違います。一方の受理は他方の自動変換を意味しません。利用側の要件に合わせて契約を設計します。
参考資料: JSON Schema — Properties, required fields and additional properties
追加の項目を許すか決める
単純なオブジェクトのスキーマではadditionalProperties: falseが未定義項目を拒否します。名前の誤記を発見できますが、契約を広げる際は意図的な更新が必要です。
必須項目なし、型違い、追加項目ありの例を試します。各例で何を検証したいか決めると結果が理解しやすくなります。
参考資料: JSON Schema — Properties, required fields and additional properties
適合してもリクエストの承認ではない
ToolRoofはDraft 2020-12の一部をローカルで検証します。外部スキーマを取得せず、すべてのキーワードには対応しません。非対応は黙って合格にせず報告します。
合格は商品の実在、データベース上の価格、ユーザー権限を証明しません。defaultの注釈も、この検証器では欠けた入力項目を埋めません。
例：暗黙の型変換なしで必須の数量を確かめる
quantityはinteger、最小値1、requiredに含め、追加項目を禁止します。{"quantity":3}は合格し、{"quantity":"3"}は型違いで失敗します。
{}は項目不足、{"quantity":3,"note":"draft"}は追加項目で失敗します。3が合格しても在庫が3個ある証拠ではありません。それはこの規則の対象外です。