解決したい課題
現在、顧客情報の作成および更新に使用するリクエストスキーマ(PostCustomerRequest, PatchCustomerRequest)において、スキーマ検証が緩く定義されており、クライアント側の実装バグやタイポの検知が遅れるリスクがあります。
- タイポや未知のキーの黙認:
additionalProperties が未指定(デフォルト true)のため、クライアントが誤ったキー名(例: emial)を送信してもスキーマ検証を素通りし、バックエンドで単に無視されて 200 OK や 201 Created が返ってしまいます。
- 空の更新の許容: 部分更新(
PATCH)において、更新する項目が一つもない完全に空のオブジェクト {} を送信することが許容されています。
達成したい要件・仕様設計
APIの堅牢性を高め、クライアント側の不具合を早期発見するため、以下のバリデーションを導入します。
PatchCustomerRequest に minProperties: 1 を追加
- 空のオブジェクト
{} による部分更新リクエストを 400 Bad Request で弾くようにします(最低1項目の更新キーを要求)。
PostCustomerRequest および PatchCustomerRequest に additionalProperties: false を追加
- スキーマに定義されていない未知のプロパティが含まれているリクエストを
400 Bad Request(スキーマバリデーションエラー)で弾くようにします。
解決したい課題
現在、顧客情報の作成および更新に使用するリクエストスキーマ(
PostCustomerRequest,PatchCustomerRequest)において、スキーマ検証が緩く定義されており、クライアント側の実装バグやタイポの検知が遅れるリスクがあります。additionalPropertiesが未指定(デフォルトtrue)のため、クライアントが誤ったキー名(例:emial)を送信してもスキーマ検証を素通りし、バックエンドで単に無視されて200 OKや201 Createdが返ってしまいます。PATCH)において、更新する項目が一つもない完全に空のオブジェクト{}を送信することが許容されています。達成したい要件・仕様設計
APIの堅牢性を高め、クライアント側の不具合を早期発見するため、以下のバリデーションを導入します。
PatchCustomerRequestにminProperties: 1を追加{}による部分更新リクエストを400 Bad Requestで弾くようにします(最低1項目の更新キーを要求)。PostCustomerRequestおよびPatchCustomerRequestにadditionalProperties: falseを追加400 Bad Request(スキーマバリデーションエラー)で弾くようにします。