이전 글에서는 JSP 기반 MVC2 방식과 API 기반 구조의 차이를 간단히 살펴봤습니다.
이번 글에서는 그 연장선으로, REST API가 왜 등장했고, 어떤 개념과 방식을 가지는지를 중심으로 정리해 보려고 합니다.
REST의 등장 배경
전통적인 웹 애플리케이션은 서버가 화면을 직접 생성하여 반환하는 구조가 일반적이었습니다.
(지난 글에서 언급한 JSP 기반 MVC2 웹 앱처럼.)
하지만 프론트엔드 기술이 발전하고, 모바일 앱이나 SPA(Single Page Application)와 같은 다양한 클라이언트가 등장하면서 서버가 화면까지 책임지는 구조에는 점차 한계가 생기기 시작했습니다.
이러한 흐름 속에서 서버는 화면이 아닌 ‘데이터 제공자’ 역할에 집중하고,
클라이언트는 받은 데이터를 바탕으로 화면을 구성하는 방식이 필요해졌습니다.
REST는 이러한 요구 속에서 등장한
웹 자원을 효율적으로 다루기 위한 아키텍처 스타일입니다.
Resource 중심 사고
REST API에서 가장 중요한 개념은 Resource(자원) 입니다.
기존 방식에서는
- “회원 조회를 한다”
- “게시글을 등록한다”
와 같은 행위 중심의 사고가 강했다면,
REST에서는 모든 것을 자원(Resource) 으로 바라봅니다.
예를 들어,
- 사용자 목록 →
/users - 특정 사용자 →
/users/1 - 게시글 목록 →
/posts
와 같이, 무엇을 할 것인지가 아니라, 무엇을 다루는지에 집중합니다.
HTTP Method의 의미
REST API에서는 같은 URI라도
HTTP Method에 따라 동작이 달라집니다.
| Method | 의미 |
|---|---|
| GET | 조회 |
| POST | 생성 |
| PUT | 전체 수정 |
| PATCH | 일부 수정 |
| DELETE | 삭제 |
즉 같은 URI를 두더라도 어떤 Method로 요청하느냐에 따라 역할이 결정됩니다.
이 방식은 동사를 포함하는 긴 URI 대신, 구조를 단순하게 유지하면서도
명확한 의도를 전달할 수 있다는 장점이 있습니다.
JSON 기반 응답 방식
REST API에서는 서버가 화면을 직접 반환하지 않고,
주로 JSON 형태의 데이터를 응답으로 전달합니다.
예를 들어 사용자 조회 요청에 대한 응답은 다음과 같습니다.
{
"id": 1,
"name": "엄태수",
"email": "taesu@example.com"
}서버는 데이터만 전달하고,
이 데이터를 어떻게 화면에 표현할지는 클라이언트의 책임이 됩니다.
이로 인해
- 프론트엔드와 백엔드의 역할이 명확해지고
- 다양한 클라이언트에서 동일한 API를 재사용할 수 있습니다.
정리
한마디로 REST API는 자원을 중심으로 사고하고, 서버의 역할을 명확히 분리하려는 접근 방식입니다.
