REST API에 대해 설명해보세요.
'어.. POST,GET,Delete로.. 통신하는....'
웹 개발을 하다 보면 “REST API”라는 말을 정말 자주 듣습니다.
하지만 막상 물어보면,
정확하게 설명하기 어려운 개념이기도 합니다.
이번 글에서는
우리가 사용하는 REST API가 무엇인지,
왜 중요한지, 기초부터 철학까지 정리해보겠습니다.
1️⃣ API란 무엇인가?
API는 Application Programming Interface의 약자입니다.
쉽게 말하면,
프로그램과 프로그램이 서로 대화하는 방법
입니다.
예를 들어,
프론트엔드에서 버튼을 클릭했을 때
서버에 데이터를 요청하고 응답을 받습니다.
이때 사용하는 약속된 통신 규칙이 바로 API입니다.
2️⃣ REST란 무엇인가?
REST는 Representational State Transfer의 약자입니다.
많은 사람들이 REST를
“GET, POST로 CRUD 하는 방식”이라고 이해합니다.
하지만 REST는 기술이 아니라
웹을 설계하는 아키텍처 스타일(철학)입니다.
그래서 REST가 뭔데?
REST = 'Representational' 'State' 'Transfer'
단어를 하나씩 해체해보겠습니다.
- Representational → 표현의
- State → 상태
- Transfer → 전송
이 세 단어가 합쳐진 개념입니다.
① State — 상태
여기서 말하는 상태는
“서버가 가지고 있는 자원의 상태”입니다.
예:
- 게시글의 내용
- 사용자 정보
중요한 점은,
상태는 서버에 존재한다는 것입니다.
클라이언트는 상태를 직접 가지지 않고,
요청을 통해 그 상태를 받아옵니다.
② Representation — 표현
클라이언트는 서버 상태 그 자체를 받지 않습니다.
대신, 서버 상태를 “표현(Representation)”한 데이터를 받습니다.
이 부분이 REST에서 가장 중요한 개념 중 하나입니다.
🔎 왜 ‘표현’이라고 부를까?
서버 내부에는 실제 데이터가 존재합니다.
예를 들어:
- 데이터베이스 레코드
- ORM 객체
- 메모리에 올라간 클래스 인스턴스
하지만 클라이언트는
이 내부 구조를 직접 알 수도 없고,
알 필요도 없습니다.
서버는 자신의 내부 상태를
외부로 전달 가능한 형태로 “변환”해서 보냅니다.
예:
{
"id": 1,
"name": "Jun"
}이 JSON 데이터는
서버 내부 상태 그 자체가 아니라,
그 상태를 외부에 보여주기 위한 표현(Representation) 입니다.
💡 중요한 포인트
Representation은 다음을 의미합니다.
서버 자원의 상태를
특정 포맷(JSON, XML, HTML 등)으로 표현한 결과
즉,
- 상태(State)는 서버 안에 존재하고
- 표현(Representation)은 클라이언트에게 전달되는 데이터입니다.
🔁 예시로 이해해보기
서버 내부:
User 객체
- id: 1
- name: "Jun"
- password: "hashed_pw"
- created_at: 2024-01-01
클라이언트에게 전달하는 표현:
{
"id": 1,
"name": "Jun"
}여기서 중요한 점은,
비밀번호는 포함되지 않습니다.
created_at도 포함되지 않을 수 있습니다.
즉,
Representation은 상태의 “전체”가 아니라
외부로 노출하기로 결정한 “선택된 모습”입니다.
🌐 그래서 왜 이게 중요한가?
Representation 덕분에
서버는 내부 구현을 자유롭게 바꿀 수 있습니다.
클라이언트는 데이터 구조의 세부사항을 몰라도 됩니다.
동일한 상태를 여러 방식으로 표현할 수도 있습니다.
(JSON,XML,HTML 등)
REST에서 말하는 “Representational State Transfer”는
바로 이 과정을 의미합니다.
서버의 상태를 직접 공유하는 것이 아니라,
그 상태를 표현한 결과만을 전송하는 것입니다.
③ Transfer — 전송
이 표현된 상태가
HTTP를 통해 전송됩니다.
클라이언트는 요청(Request)을 보내고,
서버는 상태를 표현한 데이터(Response)를 보냅니다.
이 흐름이 바로 State Transfer입니다.
🔎 그래서 REST는 무엇인가?
정리하면,
- 서버에는 자원의 상태(State)가 있고
- 클라이언트는 서버에서 결정한 그 상태의 표현(Representation)을 받으며
- 그 표현이 네트워크를 통해 전송(Transfer)됩니다.
한번 더 정리하면,
REST는 웹(HTTP) 아키텍처를 기반으로 한 자원 중심 설계 스타일입니다.
그리고 이 REST함을 지키기 위해 필요했던,
우리에게 친숙하고 부수적인 제약 조건들이
이제서야 왜 필요했는지 조금은 이해할 수 있을 것입니다.
REST의 핵심 제약 조건
REST는 몇 가지 제약(Constraints)을 가집니다.
이 제약을 지킬 때 웹처럼 확장 가능한 시스템이 됩니다.
① Client-Server
클라이언트와 서버의 역할을 분리합니다.
- 클라이언트 → 사용자 인터페이스
- 서버 → 데이터와 상태 관리
이 구조 덕분에 서로 독립적으로 발전할 수 있습니다.
② Stateless (무상태)
각 요청은 독립적이어야 합니다.
서버는 이전 요청을 기억하지 않습니다.
이 덕분에:
- 서버 확장이 쉬워지고
- 요청이 어디로 가든 동일하게 처리할 수 있습니다.
웹이 대규모 트래픽을 처리할 수 있는 이유입니다.
③ Cacheable
응답은 캐시 가능해야 합니다.
브라우저가 이미지를 저장해두고
다시 요청하지 않는 것처럼,
네트워크 비용을 줄일 수 있습니다.
④ Uniform Interface
REST의 핵심은 일관된 인터페이스입니다.
- 자원은 URL로 표현하고
- 행동은 HTTP 메서드로 정의합니다.
예:
GET /users
POST /users
GET /posts/1
이 구조가 바로 REST의 핵심입니다.
Uniform Interface 덕분에
클라이언트는 서버 내부 구조를 몰라도 됩니다.
⑤ Layered System
시스템은 계층적으로 구성될 수 있습니다.
클라이언트는
직접 서버와 통신하는지,
중간 프록시를 거치는지 알 필요가 없습니다.
확장성과 보안이 쉬워집니다.
⑥ Code on Demand (선택적)
서버가 코드를 내려보낼 수도 있습니다.
대표적인 예가 JavaScript입니다.
REST는 CRUD가 아니다
GET → 조회
POST → 생성
PUT → 수정
DELETE → 삭제
이것은 REST의 일부일 뿐입니다.
REST의 진짜 본질은:
- 자원 중심 설계
- 상태 표현 전송
- 무상태 구조
- 인터페이스의 일관성
입니다.
CRUD는 그 결과물이지, 핵심이 아닙니다.
왜 지금도 REST가 중요한가?
GraphQL, gRPC 같은 기술이 등장했지만
REST는 여전히 가장 널리 사용됩니다.
그 이유는 단순합니다.
REST는 웹의 구조 자체이기 때문입니다.
웹을 이해하면 REST가 보이고,
REST를 이해하면 웹이 보입니다.
한 문장 정리
REST API는
REST 아키텍처 스타일을 따르며
서버 자원의 상태를 표현한 데이터를
HTTP 기반의 일관된 인터페이스로 제공하는 API이다.
조금 더 풀어 말하면,
- API는 프로그램 간 통신 인터페이스이고
- REST는 웹을 설계하는 아키텍처 스타일이며
- REST API는 그 철학을 적용해 설계된 HTTP 기반 인터페이스입니다.
만약 이 문장이 여전히 추상적으로 느껴진다면,
다시 한번 떠올려보면 됩니다.
Representational — 표현
State — 상태
Transfer — 전송
서버의 상태를 직접 공유하는 것이 아니라,
그 상태를 “표현”한 결과를 전송하는 것.
그것이 REST이고,
그 방식을 따르는 인터페이스가 REST API입니다.
REST API를 이해하면
이제 GET, POST를 단순한 CRUD 도구로 보지 않게 됩니다.
URL은 자원을 나타내고,
HTTP 메서드는 의도를 표현하며,
응답은 상태의 표현입니다.
이 구조를 이해하는 순간,
대부분의 웹 API는 더 이상 낯설지 않게 됩니다.
