API構成と責務分離の基本

はじめに

この記事はAPI構成や責務分離とは何かを紹介し、API構成や責務分離がどのような歴史をたどって現在に至るのかを説明していきます。

✅ 1. APIとは？

API（Application Programming Interface）とは、
ソフトウェア同士がやり取りするための「窓口（インターフェース）」です。

アプリケーションは、APIを通じて「何ができるか」「どのようなデータを渡せばよいか」だけを知ればよく、 内部でどのような処理が行われているかを意識する必要はありません。

🔧 例：レストランでの注文

APIの仕組みはレストランによく例えられます。

• API：メニュー（注文できる内容の一覧）
• クライアント：お客さん（注文＝リクエストを送る）
• サーバー：厨房（料理＝レスポンスを返す）

💡 ポイント
お客さんは「どうやって調理されているか（内部ロジック）」を知らなくても、
メニュー（API）さえ見れば料理を受け取れます。
この 内部実装を隠蔽できる点 が、APIの最大の利点です。

✅ 2. API構成とは？

API構成とは、APIを「安全・分かりやすく・長く使える形」で提供するための
設計ルールや構造全体を指します。

主な構成要素

1. エンドポイント
   • URL（どこにアクセスするか）
2. HTTPメソッド
   • GET / POST / PUT / DELETE（何をするか）
3. リクエスト・レスポンス
   • 入力データと返却データの形式
4. 認証・認可
   • 誰が利用できるか
5. バージョン管理
   • v1 / v2 などによる後方互換性の維持
6. レート制限
   • 過剰アクセス防止・安定運用のための制御

✅ 3. 責務分離の歴史

アプリケーションが大規模・複雑になるにつれて、
「どこまでを誰が担当するか（責務）」を明確に分ける必要が生まれました。

🕰 1980s：モノリシック構成

• 特徴：UI・ロジック・DBが1つの巨大なプログラムに集約
• 技術：C / COBOL / メインフレーム
• 構造：関数単位の分離はあるが、全体は密結合

👉 小規模では問題ないが、変更に弱い構成

🕰 1990s：オブジェクト指向と3層アーキテクチャ

• 特徴：クラスに責務を持たせ、層（レイヤー）で分離
• 技術：Java / C++ / CORBA
• 構造：
  • プレゼンテーション層
  • ビジネスロジック層
  • データアクセス層

👉 単一責任の原則（SRP） が意識され始める

🕰 2000s：Web API（REST / SOAP）

• 特徴：フロントエンドとバックエンドがネットワーク越しに分離
• 技術：XML / SOAP / REST / PHP / JAX-RS
• 構造：サービス指向アーキテクチャ（SOA）

👉 API仕様＝契約 という考え方が重要に

🕰 2010s：マイクロサービスとAPIファースト

• 特徴：1サービス＝1責務で小さく分割
• 技術：Node.js / Go / Docker / Kubernetes / OpenAPI
• 構造：
  • マイクロサービスアーキテクチャ
  • ドメイン駆動設計（DDD）

👉 スケーラビリティとチーム分業を重視

🕰 2020s：サーバーレス・BFF・モダン構成

• 特徴：クライアントごとに最適なAPI（BFF）を提供
• 技術：TypeScript / AWS Lambda / GraphQL / gRPC
• 構造：
  • サーバーレスによる機能単位分割
  • 可観測性（Observability）の重視

▼ 歴史まとめ

✅ 4. モダンWebアプリケーションの階層化アーキテクチャ（レストラン例）

モダンなWebアプリケーションでは、
MVCやレイヤードアーキテクチャに基づいた分離が一般的です。

レストラン例での対応関係

👉 Controllerを薄く保ち、Serviceにロジックを集約するのが重要です。

✅ 5. 各層ごとに起きやすいバグ

責務が明確だと、バグの原因特定が容易になります。

✅ さいごに

責務分離のメリット

• 単体テストがしやすい
• 変更に強い設計になる
• チーム開発での分業が容易

責務分離は「コードを綺麗にするため」ではなく、
「開発スピードと品質を守るための設計思想」です。

要点整理