カテゴリー: 応用編

応用編

第26回: JWTによる認証 — ステートレスな「自己完結するトークン」の仕組み

複数サーバーで負荷分散するAPIや、モバイルアプリとWeb API間の認証では、サーバー側にセッションを持つと状態管理が複雑になります。「どのサーバーがセッションを持っているか」を共有するためにRedisやスティッキーセッションが必要になるからです。

matty • 1 min read

応用編

/api/users エンドポイントを作ったとき、認証がなければ世界中の誰でもアクセスできてしまいます。ユーザーデータや機密情報を扱うAPIには必ず「このリクエストは誰から来ているか」を確認する仕組みが必要です。

matty • 1 min read

応用編

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