Year

年: 2026年

応用編

第24回: リクエストバリデーション設計 — 「不正なデータはAPIの入口で止める」

if (empty($request->title)) { return error(); } をコントローラに書き続けると、バリデーションロジックが散らばり、テストも困難になります。複数のエンドポイントで同じルールが重複し、変更のたびに複数箇所を修正しなければなりません。

matty • 1 min read

応用編

エラーがあっても { “success”: false } を200で返すAPIがあります。クライアントはHTTPステータスだけでは「成功か失敗か」が分からず、常にJSONのパースが必要になります。

matty • 1 min read

応用編

成功時は { “user”: {…} }、エラー時は { “msg”: “error” }、別のエンドポイントでは { “result”: “OK” } ——。

matty • 1 min read

応用編

URLにアクション名を含めるAPI設計は、慣れれば作れても「APIを使う側」にとっては覚えるルールが増えるだけです。

matty • 1 min read

応用編

ユーザーが投稿を削除したあと、「やっぱり復元したい」と言われたら？法的な理由でデータを保持しなければならない場合は？物理削除（レコードの完全消去）は取り返しがつきません。

matty • 1 min read

応用編

開発者Aはユーザーを手動で5件登録している。開発者BはDB初期化後に1件しかない。CI環境には何もない——。こうした「環境ごとのデータ差異」がテスト結果の不一致や、動作確認の手戻りを引き起こします。

matty • 1 min read

応用編

コントローラAでも、サービスクラスBでも、同じ ->where(‘status’, ‘published’) を繰り返し書いていませんか？もし「公開済み」の定義が変わったら、すべての箇所を変更しなければなりません。

matty • 1 min read

応用編

投稿の著者を取得するたびに WHERE id = ? を書くのは非効率です。Eloquentのリレーションを使えば、$post->user->name と書くだけで関連データを取得できます。

matty • 1 min read

応用編

PDOで直接SQLを書くと、取得・作成・更新・削除のたびに似たようなクエリを書き続けることになります。テーブルの構造が変わればクエリも直していかなければなりません。

matty • 2 min read

応用編

$sql = “SELECT FROM users WHERE active = 1″ に条件を追加するたびに $sql .= ” AND name LIKE ‘%{$name}%'” と書いていると、SQLインジェクションのリスクが忍び込みます。

matty • 2 min read