説明
IDやコードなど形式が決まっている文字列は、長さの制限だけでは妥当性を確認できません。必要な pattern 制約がなければ、形式の異なる値もスキーマの検証を通る可能性があります。自由記述の文字列に常に正規表現が必要なわけではありません。
想定される影響
サーバーでも形式を検証しない場合、不正な値によって後続の処理でエラーが発生する可能性があります。文書と実装で入力の条件が食い違うこともあります。
対処方法
許可する形式に合わせて pattern を定義し、サーバーの検証と一致させてください。enum などですでに必要な形式を制限している場合は、同じ制約を重ねる必要はありません。
例
次のOpenAPI 3.0の抜粋では、code と message の両方がASCIIの英小文字と数字からなる15文字のコードであると仮定し、パターンを追加しています。自由記述のメッセージに一律に適用する規則ではありません。
変更前
json
{
"components": {
"schemas": {
"GeneralError": {
"properties": {
"code": {
"type": "string",
"maxLength": 15
},
"message": {
"type": "string",
"maxLength": 15
}
}
}
}
}
}
変更後
json
{
"components": {
"schemas": {
"GeneralError": {
"properties": {
"code": {
"type": "string",
"maxLength": 15,
"pattern": "^[0-9a-z]{15}$"
},
"message": {
"type": "string",
"maxLength": 15,
"pattern": "^[0-9a-z]{15}$"
}
}
}
}
}
}