本記事は執筆デビューWeek 10日目の記事です。
✨ 9日目 ▶▶ 本記事 ▶▶ 11日目 🔰

初めに

初めまして。9月にキャリア入社した芳賀と申します。前職ではオンプレミス環境+MVC構成のWebアプリのエンジニアをしておりました。現在はAmazon ECS+REST API（Spring Boot）+SPA構成のバックエンドエンジニアをしており、入社前後でアーキテクチャ構成がかなり変わって四苦八苦しております(笑)

そこで、2か月間の経験をもとにMVC/REST APIの差で困ったポイントをまとめてみました。今後アーキテクチャ変更に取り組まれようとしている方の一助になればと思います。

MVCとREST APIの違い

MVCとREST APIの違いは大きく3点に分けられます。

ビュー層の構成

MVC → HTMLをサーバ側で構築
REST API → バックエンドはJSON/XMLを返し、フロントエンド（SPA）でHTMLを構築

MVCでは通常サーバ側で生成したHTMLをブラウザに返しますが、REST APIの場合、バックエンドはデータを入れたオブジェクト（たいていはJSON）を返すだけで、HTMLの構築はフロントエンドが担当します。MVCではHTMLのテンプレートエンジン（SpringであればThymeleaf）、REST APIの場合はJavaScript（現在はTypeScriptも多い）でHTMLを生成します。

認証・認可アーキテクチャ

MVC → ユーザ/パスワードをシステム内に保持してその情報で認証+認証情報に基づいた認可制御の実装
REST API → OAuthなどのトークンベースの認証・認可フローの構築

認証についてはMVC（というかモノリシック）な構成であれば、ログイン画面で入力したID/パスワードをもとに一度認証したら終了です。一方、REST API+SPAであれば、まずはSPA側で入力したID/パスワードを共にリソースサーバでトークンを発行、発行したトークンをバックエンドに渡し、トークンが有効かどうかチェックして、バックエンドに連携する、といったフローを構築する必要があります。

認可にしても、MVCであればログインした情報をセッションに保持して、セッション情報内に設定した認証情報で認可を行う、という構成が多いと思います。一方、トークンベースの認証の場合はリクエストヘッダ等に保持したトークンをリソースサーバに渡して認可処理を行う、という構成になります。

サービス構成

MVC → Webアプリケーションサーバ上に、モノリシックサービスを構築
REST API → コンテナなどを活用した複数のサービスを連携させる構成

これは商環境によると思われますが、MVC構成をとるような場合は単一のサービスとしてモノリシックなアーキテクチャをとることが多いと思います。REST APIの場合はDockerなどを活用し、アクターやドメインに応じた複数サービス構成をとることが多くなる印象です。

REST API+SPA構成のメリット/デメリット

メリット → 疎結合なシステムを作りやすく、拡張性が高くなる（サービスごとにアプリが分かれるので必要部分のみスケールアウトができる/機能エンハンス時の影響が特定しやすく改修しやすい）
デメリット → 構成が複雑になりやすく、適切にサービス分割を行わないと疎結合の利点を生かしづらい

MVC構成のメリット/デメリット

メリット → 構成がシンプルになるため、小規模システムであれば構築が容易
デメリット → 密結合なシステムになりやすいため、拡張性が低くなる（一部分のリソース不足であっても全体をスケールアウトしなくてはならない/機能エンハンス時の影響が見えにくく改修が難しい）

総括

アーキテクチャ選択のポイントとしては、小規模なシステムで今後の拡張性をそれほど考慮しなくてもよい場合は、MVCアーキテクチャを選択したほうが利点が多いと考えます。逆に、中規模以上のシステムや今後の拡張が見込まれる場合や、外部にAPIを提供したりする場合はREST APIアーキテクチャを選択したほうが利点が多いと考えます。ビジネス要件に応じて適切なアーキテクチャを選択しましょう。