controller層の入力バリデーション強化（型変換と 400 レスポンス整備）

[taminororo]

概要

controller 層で経路パラメータ（c.Param）・クエリパラメータ（c.QueryParam）の型変換と入力バリデーションを行い、不正な入力に対して適切に 400 Bad Request を返すように整備する。

背景・動機

• 現状、c.Param("id") で取得した値を文字列のまま usecase / repository 層に流している
• 結果として、不正な入力（数値でない文字列、空文字、極端な長さ等）が DB 層まで到達して 500 を返すケースがある
• 適切な層（controller）で弾くことで：
  • エラーレスポンスが 400 に整い、API のセマンティクスが正しくなる
  • 内部実装（DB エラー）が漏れない
  • usecase / repository 層の前提が単純化される

実装内容（案）

数値ID系パラメータ

• c.Param("id") で取得 → strconv.Atoi(id) でパース
• パース失敗時は c.JSON(http.StatusBadRequest, ...) で 400 を返す
• 対象：/users/:id, /tasks/:id, /shifts/:id, /reviews/:id など全ID系エンドポイント

文字列パラメータ

• 長さ制限（例：name は 255 文字以内）
• 必須項目の空文字チェック

リクエストボディ系

• c.Bind(&req) の戻り値ハンドリングを統一
• バリデータタグの活用検討（go-playground/validator 等）

対象ファイル

• api/lib/internals/controller/*.go 全ファイル（controller 層全体）

テスト項目

• 不正な ID（文字列、空文字、極端に長い文字列）で 400 が返ること
• 正常な ID で従来通り 200/201/204 が返ること
• 既存テストが通ること

進め方

全 controller を一度に直すと PR が大きくなるので、ドメインごとに分割推奨：

• users / sessions 系
• tasks / shifts 系
• reviews / rescue 系
• master 系（bureaus, grades, places 等）

備考

• バリデーションライブラリ（go-playground/validator など）の導入の是非も合わせて検討
• 共通ヘルパー関数（例：parseIDParam(c)）を作って重複を避ける