まとめ

この講義では、Web APIの設計から実装までの一連の流れを扱ってきました。

• RESTに従うことで、HTTPメソッドとURLだけでAPIの振る舞いが予測できるようになります
• フレームワークがHTTP解析やルーティングを引き受けることで、開発者はビジネスロジックだけを書けばよくなります
• コードを責務ごとに分けることで、変更が必要になったとき影響する範囲を限定できます
• Linter・Formatterが機械的にコードの問題を検出・修正することで、人間のレビューはロジックに集中できます
• 型を書くことで、実行する前に不正な値の混入を防ぐことができます

今回扱った技術や仕組みには、それぞれ解決したい問題があります。

• RESTに従うのは、APIの使い方をチーム内外で共有しやすくするため
• フレームワークを使うのは、開発者がビジネスロジックだけに集中できるようにするため
• コードを責務ごとに分けるのは、変更の影響範囲を限定するため
• Linterを使うのは、実行する前に潜在的なバグを見つけるため
• Formatterを使うのは、スタイルの違いを議論の対象から外すため
• 型を書くのは、実行する前に不正な値の混入を防ぐため

「FastAPIを使うこと」「レイヤードアーキテクチャにすること」自体が目的ではありません。

何を解決するために導入しているのかを常に意識してください。

理由なく仕組みを増やすと、それ自体が複雑さになります。

終わりに

この講義で扱った内容は、バックエンド開発の入り口にすぎません。

実務では今回触れなかったテーマに数多く出会うことになります。

そのとき大事なのは、特定の技術やパターンの知識よりも、「なぜこう設計されているのか」を考える姿勢です。

自分で手を動かした経験を大切にしてください。

「こう書いたらこう動いた」という体験と、「なぜそう設計するのか」という問いが結びついたとき、それが本当の理解になります。