REST API와 Spring MVC 흐름 정리
웹 서비스에서 화면이 보이고 데이터가 오가는 과정은 크게 2가지 관점으로 나눠서 볼 수 있다.
(1) 서버 내부에서 요청을 컨트롤러로 라우팅하고 처리하는 구조(Spring MVC)
(2) 정적 리소스(HTML/CSS/JS)를 받아서 브라우저가 실행하는 흐름(REST API 기반)
MVC 패턴 (Spring MVC 기준)
스프링에서 말하는 MVC는 “요청을 어떻게 받아서(Controller), 어떤 데이터를 만들고(Model), 어떤 형태로 응답할지(View)”를 역할로 나눈 구조임.
그리고 이 전체 흐름을 앞단에서 조정하는 중심에 DispatcherServlet이 존재함.
Spring MVC 패턴
Model(모델)
스프링 MVC에서 “Model”은 2가지 의미로 자주 쓰인다.
- (1) 비즈니스/도메인 모델: Service/Domain에서 규칙과 데이터를 다루는 객체들(엔티티/도메인/DTO 등)
- (2) View에 전달하는 Model: Controller가 View로 내려줄 데이터를
Model(또는ModelAndView)에 담아 전달하는 것View(뷰)
- 최종 결과 화면을 렌더링하는 역할이다(Thymeleaf/JSP 등 템플릿 엔진 기반).
- API 서버인 경우 화면 대신 JSON을 내려준다. 이때 View는 “JSON 응답 생성”으로 대체되는 것으로 이해하면 된다(
@ResponseBody,@RestController사용).Controller(컨트롤러)
- HTTP 요청을 가장 먼저 받는 진입점이다.
- URL/HTTP 메서드에 따라 실행될 메서드를 매핑한다.
- 요청 파라미터/바디를 객체로 바인딩한다(DTO 등) 및 검증 수행한다.
- 비즈니스 로직은 직접 처리하지 않고 Service에 위임한다.
Spring MVC 처리 절차
JSP, 타임리프와 같은 템플릿 엔진을 가지고 화면을 렌더링하는 처리형태다
- 서버에서 최종 HTML 결과를 만들어 브라우저로 전달
- Controller가 요청을 처리하고, Model에서 데이터를 가져와 View(화면)를 구성
- 주로 복잡한 프론트엔드 로직이 필요 없는 단순한 페이지에 적합한 방식
Spring MVC의 핵심 구성 요소
DispatcherServlet(프론트 컨트롤러)
- 스프링 MVC의 앞단에서 요청 흐름을 중앙에서 조정하는 구성요소이다.(진입점)
- 실무에서 스프링 MVC 동작 방식을 이해하는 핵심 축이다.
HandlerMapping
- 요청 URL을 기반으로 어떤 컨트롤러가 해당 요청을 처리할지 결정
Controller
- HandlerMapping이 결정한 컨트롤러의 메서드가 요청을 처리하고, 모델 데이터를 준비한 다음, 보여줄 뷰의 이름을 반환
ViewResolver
- 최종적으로 사용자에게 보여질 UI를 렌더링
- 컨트롤러가 "home"이라는 뷰 이름을 반환하면, ViewResolver는 이를 home.jsp 또는 home.html과 같은 실제 뷰 파일로 해석(뷰 이름 해석)
- Thymeleaf 뷰 템플릿을 사용시 ThymeleafViewResolver
- JSP를 사용시 InternalResourceViewResolver
View
- 컨트롤러로부터 전달받은 모델 데이터를 사용하여 HTML, JSON, XML 등의 형태로 클라이언트에게 응답을 생성
Spring MVC 요청 흐름(웹 페이지 렌더링 기준)
- 사용자(브라우저) → 서버: 요청 발생
사용자 URL 접속/버튼 클릭/폼 제출 발생한다.
브라우저에서 HTTP 요청 전송한다. - DispatcherServlet: 요청을 가장 먼저 수신
요청 처리 담당 컨트롤러 탐색 시작한다.
3) HandlerMapping → Controller 결정
요청 URL/HTTP 메서드에 매핑된 컨트롤러 메서드 조회 및 연결한다. - Controller: 요청 처리 준비
쿼리 파라미터, path variable, body(JSON 등) 바인딩한다.
검증 수행한다.
비즈니스 로직은 직접 처리하지 않고 Service에 위임한다. - Service: 핵심 비즈니스 로직 처리
주문 생성/회원가입/결제 검증 등 도메인 규칙 수행한다.
필요 시 트랜잭션 처리 발생한다.
Repository/Mapper 호출한다. - Repository(또는 Mapper) → DB 통신
JDBC/MyBatis/JPA 등을 통해 DB CRUD 수행한다.
해당 구간은 HTTP 통신 아님. DB 드라이버/프로토콜 기반 질의/응답이다. - DB → Repository/Service → Controller: 결과 반환
DB 결과를 엔티티/도메인/DTO로 매핑한다.
서비스 결과를 컨트롤러로 반환한다. - Controller → View로 데이터 전달
서버사이드 렌더링인 경우 Model에 데이터 담는다.
View 이름(어떤 화면 보여줄지) 반환한다. - ViewResolver → View(템플릿) 선택
View 이름을 실제 템플릿(Thymeleaf/JSP 등)으로 매핑한다. - View 렌더링 → 사용자 응답(HTML)
최종 HTML 생성된다.
HTTP Response로 브라우저에 전달된다.
브라우저에서 화면 렌더링 발생한다.
스프링 MVC 요청 흐름(API 서버 기준: @RestController)
위 흐름 중에서 8~10단계가 변경된다.
- Controller가 View 이름 반환하지 않는다. 객체 자체 반환한다.
- 스프링이 객체를 JSON 등으로 변환하여 응답 바디에 담아 내려준다.
- 즉 템플릿 렌더링 대신 “응답 바디 생성”이 최종 단계가 된다.
헷갈리기 쉬운 포인트(실무에서 자주 발생함)
- 스프링에서 말하는 MVC는 실무에서
Controller - Service - Repository로 더 세분화되어 운영되는 경우 많다. Controller는 Model을 직접 다루기보다 Service에 위임하는 구조가 일반적이다. - “Model”이라는 용어가 도메인 모델 의미로도 쓰이고, View에 전달하는 데이터(Model 객체) 의미로도 쓰인다. 문맥 구분 필요하다.
REST API
RESTful API는 "Representational State Transfer"의 약어로, 웹 표준을 사용하여 서버와 클라이언트 간의 상호 작용을 정의하는 방법
REST API 패턴
예시 이미지처럼, 화면 렌더링은 Vue 등의 프론트엔드 프레임워크가 담당하고 Spring 서버는 데이터만 전달하는 RESTful API 아키텍처를 사용한다.
이러한 방식이 바로 CSR(Client-Side Rendering) 에 해당한다.
REST API 특징
리소스 기반
- 모든 것은 리소스(데이터 또는 서비스)로 간주하며, 각 리소스는 고유한 URI를 가진다.
예:http://localhost:8080/member/1→ 회원 1에 접근
스테이트리스(Stateless) 통신
- 서버가 이전 요청 상태를 저장하지 않으며, 각 요청은 자체적으로 완전한 정보를 포함해야 한다.
이는 HTTP 프로토콜의 기본 원칙이다.
표준 HTTP 메서드 사용
GET,POST,PUT,PATCH,DELETE메서드를 활용해 CRUD 작업을 수행한다.
데이터 교환 형식
- JSON, XML 같은 경량 데이터 포맷을 통해 클라이언트와 서버 간 데이터를 주고받는다.
REST API(Restful API) 요청 흐름 (프론트 정적 리소스 + API 호출)
- 사용자 → 프론트엔드(웹 서버/CDN): URL 접속
사용자가 브라우저로 특정 URL에 접속한다. - 프론트엔드 → 사용자: 정적 리소스 제공
브라우저가 HTML/CSS/JS 파일을 내려받는다. - 사용자 PC(브라우저)에서 파일 실행
내려받은 HTML/CSS/JS가 브라우저에서 실행된다.
JS 파일 내부에axios.get,axios.post,axios.delete,axios.put등으로 백엔드 서버에 보낼 요청(HTTP 요청)을 작성/실행하는 로직이 포함되어 있다. - 사용자(브라우저) → 백엔드 서버: HTTP 요청 전송
브라우저가 JS(axios) 로직에 따라 백엔드 서버로 요청 문서(HTTP Request)를 발송한다.
백엔드 서버는 요청에 따라 필요한 객체를 생성한 뒤, DB에 반영/조회하기 위한 CRUD 요청을 준비한다.
이때 DB 접근은 JDBC, MyBatis(또는 JPA 등)를 통해 수행된다. - 백엔드 서버 → DB: DB 프로토콜로 요청 전송(HTTP 아님)
백엔드 서버가 DB로 보내는 것은 HTTP 문서가 아니라, DB 벤더/드라이버가 정의한 데이터베이스 통신 프로토콜(쿼리/커맨드) 기반의 요청이다.
즉, 여기 구간은 “HTTP 요청/응답”이 아니라 “DB 질의/응답”이라고 이해하면 된다. - DB → 백엔드 서버: DB 응답 반환
DB가 CRUD를 수행한 뒤 결과를 백엔드 서버로 반환한다.
백엔드 서버는 DB 응답에 따라 필요한 객체를 생성/조립하고, 최종적으로 사용자에게 돌려줄 응답 문서(HTTP Response)를 작성한다. - 백엔드 서버 → 사용자(브라우저): HTTP 응답 전송
백엔드 서버가 사용자에게 응답 문서(HTTP Response)를 발송한다.
렌더링 방식 비교 요약
| 구분 | 처리 주체 | 특징 | 사용 예시 |
|---|---|---|---|
| SSR (Server-Side Rendering) | 서버 | HTML을 서버에서 생성 후 전달 | Thymeleaf, JSP |
| CSR (Client-Side Rendering) | 클라이언트(브라우저) | 데이터만 받아서 브라우저가 화면 구성 | React, Vue, Angular |
Eazy하게