1. REST API
REST = REpresentational State Transfer
웹 아키텍처 설계 원칙, API를 만드는 규칙 모음
| 단어 | 의미 |
|---|---|
| Representational | 리소스를 JSON, XML 같은 형태로 표현해서 |
| State | 그 리소스의 현재 상태를 |
| Transfer | 클라이언트 ↔ 서버 간에 전달한다 |
→ 서버에 있는 데이터(리소스)의 상태를 JSON 같은 표현으로 주고받는 것
핵심 개념 3가지
- 자원(Resource)
서버가 관리하는 대상 - 게시글, 회원, 상품 등 url로 식별
- 표현 + 상태 전달(Representation & State Transfer)
자원의 현재 상태를 JSON, XML 같은 형태로 응답으로 보내주는 것
{ "bno": 1, "btitle": "REST 이해하기" }→ 1번 게시글의 상태를 표현
- 행위 (HTTP Method)
자원에 무엇을 할 건지를 HTTP 메서드로 표현
| HTTP 메서드 | CRUD | 의미 |
|---|---|---|
| GET | Read | 리소스 조회 |
| POST | Create | 리소스 생성 |
| PUT | Update | 리소스 전체 수정 |
| PATCH | Update | 리소스 부분 수정 |
| DELETE | Delete | 리소스 삭제 |
REST의 6가지 설계 원칙
① Stateless (무상태성)
각 요청은 독립적이며, 서버는 클라이언트의 이전 상태를 저장하지 않는다. 매 요청마다 필요한 정보를 모두 담아서 보내야 한다.
❌ "아까 로그인했잖아, 기억하지?" ✅ 매 요청마다 인증 토큰을 같이 보냄
② Client-Server 분리
UI(클라이언트)와 데이터(서버)를 분리해서 서로 독립적으로 개발 가능.
③ Uniform Interface (일관된 인터페이스)
리소스는 URI로 식별하고, HTTP 메서드로 행동을 표현. 누가 봐도 예측 가능한 구조.
④ Cacheable (캐시 가능)
응답을 캐시할 수 있어서 성능 향상 가능.
⑤ Layered System (계층화)
클라이언트는 서버가 몇 겹인지 몰라도 돼. 중간에 로드밸런서, 프록시 등이 있어도 OK.
⑥ Code on Demand (선택적)
서버가 실행 가능한 코드(JS 등)를 전달할 수 있음.
전체를 한 문장으로
URI(자원) + HTTP 메서드(행위) + JSON(표현) 으로 서버 자원의 상태를 주고받는 API 설계 방식
2. @Controller의 역할은 무엇인가
클라이언트(브라우저, 앱 등)로부터 HTTP 요청이 들어오면, Controller가 가장 먼저 받아서 어떤 Service 로직을 호출할지 결정한다. 직접 비즈니스 로직을 수행하지 않고, Service에 위임하는 것
View(HTML 페이지) 반환, 주로 MVC(Thymeleaf, JSP 등)에서 사용한다.
→ 요청을 받고, 시키고, 돌려준다
@RestController
클라이언트(브라우저, 앱, Postman 등)에서 HTTP 요청이 들어오면, @RestController가 해당 URL과 HTTP 메서드(GET, POST, PUT, DELETE)를 보고 알맞은 메서드로 라우팅한다. 이후 Service를 호출해 비즈니스 로직을 위임하고 결과값을 받아온다.
이때 반환된 Java 객체는 Jackson 라이브러리가 자동으로 JSON으로 직렬화해서 HTTP Response Body에 담아 클라이언트에게 돌려준다.
→ JSON/XML 데이터 반환, 객체를 JSON으로 직렬화해서 반환한다. 주로 REST API에서 사용한다.
Controller와 RestController 차이점
@Controller는 반환값을 View 이름으로 해석해서 템플릿을 렌더링하지만, @RestController는 반환값 자체를 응답 본문으로 직접 쓴다. 그래서 REST API 서버처럼 화면 없이 데이터만 주고 받는 구조에서 사용한다.
