API のレスポンス設計として妥当なのはどれですか。
直接返すと、DBに列を足しただけでAPIの出力が変わり、内部の列名や出すべきでない項目まで露出します。Resource を挟めば、出す項目を明示的に決められます。
面接官が見ているのは場当たりでなく方針を持っているか。
よくある答えと、面談でどう見られるか
- モデルを直接返さず API Resource を挟み、出す項目を明示的に決める
DB の都合と API の契約を切り離すためです。エラーの形式も統一します。 - モデルをそのまま return する
列を足しただけで API の出力が変わり、内部の列名や出すべきでない項目まで露出します。 - 配列に手で詰め替えてから返す
やっていることは Resource と同じですが、同じ整形が各所に散らばります。 - 必要な項目だけ $hidden で隠して、あとはモデルを返す
指定漏れが起きた瞬間に露出します。出す方を列挙する方が安全です。
面接官は何を見ているか
- API Resource / Transformer などの層に触れた
- モデルをそのまま返す危険に触れた
- エラーレスポンスの形式にも触れた
模範解答
モデルをそのまま返さず、API Resource を挟みます。直接返すと、DBに列を足しただけでAPIの出力が変わってしまい、内部の列名や本来出すべきでない項目まで露出します。Resource を挟めば、出す項目を明示的に決められます。エラーも形式を統一して、クライアント側が分岐しやすい形にします。
ここからどう深掘りされるか
この問いに答えられた場合、面談は次の質問に進みます。
観点をすべて押さえられた場合
一覧APIで paginate() を使ったら重くなりました。なぜですか。どうしますか。一部しか触れられなかった場合
API Resource を使わずモデルをそのまま返すと、何が起きますか。