REST의 ‘정신’을 구성하는 6가지 원칙
REST(Representational State Transfer)는 “표현으로 상태를 전송한다”는 뜻인데,
이 말은 결국 “자원(Resource)을 일관된 방식으로 다룬다” 는 철학이에요.
이 철학을 실현하기 위해서는 다음 6가지 조건을 만족해야 합니다.
목차
1️⃣ 클라이언트-서버 구조 (Client–Server)
역할을 명확히 분리해야 한다.
- 클라이언트는 UI/UX 담당
- 서버는 데이터와 비즈니스 로직 담당
→ 이렇게 하면 각각 독립적으로 발전 가능
예:
- 브라우저(클라이언트)는 화면만,
- 서버(API)는 JSON 데이터만 전달
2️⃣ 무상태성 (Stateless)
서버가 클라이언트의 상태를 기억하지 않는다.
- 매 요청은 완전히 독립적
- 인증정보, 세션 등은 매번 요청에 포함해야 함 (예: JWT 토큰)
이 원칙이 깨지면 서버 확장(Scaling)이 어려워지고, RESTful하지 않아요.
예:
❌ “로그인 후 서버가 나를 기억하고 있음” → 상태 저장
✅ “모든 요청에 인증토큰을 함께 보냄” → 상태 없음
3️⃣ 캐시 처리 가능 (Cacheable)
응답 데이터는 캐싱이 가능해야 한다.
- 서버는
Cache-Control,ETag,Expires등의 헤더를 통해 캐시 여부를 알려줌 - 클라이언트는 동일 요청 시 캐시를 재사용 가능
→ 네트워크 부하 ↓, 응답 속도 ↑
4️⃣ 일관된 인터페이스 (Uniform Interface)
이게 사실상 “REST의 핵심 정신”이에요.
모든 자원에 일관된 규칙으로 접근해야 한다.
즉,
- 자원은 URL(URI)로 식별하고,
- 동작은 HTTP 메서드로 구분하고,
- 표현(Representation)은 JSON, XML 등 표준 포맷을 사용해야 함.
예를 들어:
GET /users/1 → 사용자 정보 조회
PUT /users/1 → 사용자 정보 수정
DELETE /users/1 → 사용자 삭제
이처럼 누구나 봐도 규칙이 한결같은 게 “RESTful”의 핵심이에요.
5️⃣ 계층화 시스템 (Layered System)
API 서버는 여러 계층으로 구성될 수 있다.
- 클라이언트는 중간 프록시나 로드밸런서를 몰라도 됨
- 인증, 보안, 캐시, 로깅 등은 독립 계층으로 분리 가능
즉, RESTful API는 구조적으로 확장성과 보안성을 고려한 형태여야 합니다.
6️⃣ 코드 온 디맨드 (Code on Demand) — 선택적 원칙
서버가 실행 코드를 클라이언트에 내려보낼 수 있다.
예: JavaScript 스니펫을 응답에 포함시켜 동적 실행
→ 이건 자주 쓰이진 않지만 REST의 원래 정의에 포함된 옵션이에요.
🌿 정리하자면
| REST 원칙 | 설명 | RESTful하게 지켰을 때 |
|---|---|---|
| 클라이언트-서버 | 역할 분리 | 서버는 데이터, 클라이언트는 UI |
| 무상태성 | 요청 간 독립 | 세션 대신 토큰 인증 사용 |
| 캐시 처리 | 응답 재사용 가능 | Cache-Control 헤더 제공 |
| 일관된 인터페이스 | 통일된 규칙 | 명사형 URI + HTTP 메서드 구분 |
| 계층화 | 구조적 유연성 | 보안, 로깅, 프록시 계층 추가 가능 |
| 코드 온 디맨드 | 선택 기능 | JS 등 동적 코드 전달 가능 |
🚦결론: “RESTful”의 진짜 의미
RESTful하다는 건 단순히 GET, POST를 사용하는 게 아니라
이 여섯 가지 원칙 중 최소한 핵심 네 가지(1~4)를 제대로 지킨 API 라는 뜻이에요.
즉,
✅ 자원 중심적이고,
✅ 상태를 저장하지 않으며,
✅ 일관된 규칙을 따르고,
✅ 캐시 가능한 구조라면,
그 API는 “REST의 정신을 제대로 지킨”
진짜 RESTful API라고 할 수 있습니다.
