REST API 와 Stateless 개념 정리

REST API 와 RESTful, 그리고 Stateful vs Stateless 정리

1. REST API 란?

1-1. REST 의 뜻

REST = REpresentational State Transfer
직역하면 "표현(Representation)을 통한 상태(State)의 전달(Transfer)" 이다.

• 2000년 Roy Fielding의 박사 논문에서 제안된 아키텍처 스타일(설계 원칙) 이다.
• 특정 기술이나 프로토콜이 아니라, "웹(HTTP)을 잘 쓰는 방법에 대한 약속/스타일" 이다.

1-2. 풀어서 이해하기

• Resource(자원): 서버가 다루는 모든 것(회원, 게시글, 상품 등). 각 자원은 URI로 식별된다.
  • 예: /users/1 → "1번 사용자"라는 자원
• Representation(표현): 그 자원의 상태를 표현한 데이터(보통 JSON, 예전엔 XML).
  • 예: { "id": 1, "name": "장창원" }
• State Transfer(상태 전달): 클라이언트와 서버가 이 표현(JSON 등)을 주고받으며 자원의 상태를 조회/변경한다.

1-3. REST API 란?

위 REST 원칙을 따라 만든 API(서버가 제공하는 기능 호출 규약) 를 REST API 라고 한다.

핵심은 "HTTP 메서드로 행위를 표현하고, URI로 자원을 표현한다" 는 것.

HTTP 메서드	의미(행위)	예시	설명
GET	조회	GET /users/1	1번 사용자 정보 조회
POST	생성	POST /users	새 사용자 생성
PUT	전체 수정	PUT /users/1	1번 사용자 정보 전체 교체
PATCH	부분 수정	PATCH /users/1	1번 사용자 일부 필드만 수정
DELETE	삭제	DELETE /users/1	1번 사용자 삭제

❌ 나쁜 예 (행위를 URI에 넣음): GET /getUser?id=1, POST /deleteUser
✅ 좋은 예 (자원은 URI, 행위는 메서드): GET /users/1, DELETE /users/1

---

2. "RESTful 하다" 는 게 무엇인가?

2-1. 의미

RESTful = "REST 아키텍처 원칙을 잘 지켜서 설계되었다"는 뜻의 형용사.
즉, REST API라고 다 RESTful한 건 아니다. 원칙을 제대로 지켰을 때 "RESTful 하다"고 말한다.

2-2. RESTful 하기 위한 주요 원칙(제약조건)

1. 자원 기반 URI (Uniform Interface)

   • URI는 명사(자원) 로 표현, 행위는 HTTP 메서드로.
   • GET /articles/10 (O) vs GET /getArticle?no=10 (X)

2. 계층적 자원 표현

   • GET /users/1/orders/5 → "1번 유저의 5번 주문"처럼 관계를 URI로 표현.

3. 적절한 HTTP 메서드/상태코드 사용

   • 조회=GET, 생성=POST … / 응답은 200 OK, 201 Created, 404 Not Found, 500 ... 등 의미에 맞게.

4. Stateless (무상태) ← 이번 주제의 핵심

   • 서버가 클라이언트의 이전 요청 상태를 저장하지 않는다. (아래 3장에서 자세히)

5. 표현(Representation) 일관성

   • JSON 등 일관된 형식으로 자원의 상태를 주고받는다.

6. (이상적으로는) HATEOAS

   • 응답에 "다음에 할 수 있는 행동의 링크"를 포함. (실무에선 잘 안 지켜지는 편)

2-3. 한 줄 요약

REST API = REST 스타일을 지향해 만든 API
RESTful 하다 = 그 REST 원칙을 충실히 잘 지켰다 (특히 자원/메서드/무상태)

---

3. Stateful vs Stateless (가장 중요한 핵심)

REST의 핵심 제약조건 중 하나가 Stateless(무상태) 다.
이 둘의 차이를 비유와 예시로 자세히 살펴보자.

3-1. 정의

• Stateful (상태 유지): 서버가 클라이언트의 이전 대화 상태(맥락)를 기억 한다.
• Stateless (무상태): 서버가 이전 상태를 기억하지 않는다. 각 요청은 완전히 독립적 이며, 처리에 필요한 모든 정보를 요청에 담아 보내야 한다.

3-2. 식당 비유로 이해하기 🍽️

Stateful (상태 유지) 점원

손님: "김치찌개 주세요"
점원: (기억함) "네"
손님: "아 그리고 밥 추가요"        ← '무엇에' 추가인지 안 말해도 됨
점원: "김치찌개에 밥 추가요? 네"   ← 점원이 직전 주문을 기억하고 있음

→ 점원이 바뀌면(다른 서버로 가면) 대화가 끊긴다. "무슨 주문이요?"

Stateless (무상태) 점원

손님: "김치찌개 주세요"
점원: "네"
손님: "김치찌개에 밥 추가요"        ← 매번 '무엇에'까지 전부 다시 말함
점원: "네"

→ 점원이 누구로 바뀌어도 상관없다. 매 주문이 그 자체로 완결되어 있으니까.

3-3. 실제 HTTP 요청 예시

❌ Stateful 한 방식 (서버가 상태를 기억)

# 1단계: 로그인하면 서버가 세션을 메모리에 저장
POST /login
{ "id": "cw924", "pw": "1234" }
→ 서버: 세션ID "abc" 생성하고 "abc = cw924 로그인됨" 을 서버 메모리에 저장

# 2단계: 이후 요청은 세션ID만 보냄
GET /my/orders
Cookie: sessionId=abc
→ 서버: "abc가 누구더라? 아, cw924구나" (서버가 기억해둔 상태를 꺼내 씀)

• 서버가 "누가 로그인했는지"를 자기 메모리에 들고 있다.
• 문제: 서버가 2대 이상이면? 1번 서버에 저장된 세션을 2번 서버는 모른다 → 확장 어려움.

✅ Stateless 한 방식 (요청에 모든 정보 포함, 예: JWT 토큰)

# 1단계: 로그인하면 서버가 '토큰'을 발급(서버는 따로 저장 안 함)
POST /login
{ "id": "cw924", "pw": "1234" }
→ 서버: 사용자 정보가 담긴 서명된 토큰(JWT) 발급. 서버는 아무것도 기억 안 함.

# 2단계: 이후 모든 요청에 토큰을 직접 담아 보냄
GET /my/orders
Authorization: Bearer eyJhbGciOi...(토큰 안에 'cw924' 정보가 들어있음)
→ 서버: 토큰만 검증하면 누군지 바로 알 수 있음. 이전 기억이 필요 없음.

• 서버는 아무 상태도 저장하지 않는다. 요청 자체에 "내가 누구인지"가 다 들어있다.
• 어느 서버가 받아도 동일하게 처리 가능 → 확장에 유리.

3-4. 비교 표

구분	Stateful (상태 유지)	Stateless (무상태)
상태 저장 위치	서버가 기억	저장 안 함 (요청에 다 담음)
각 요청의 독립성	이전 요청에 의존	각 요청이 완전히 독립
예시 기술	세션(Session) 기반 로그인	JWT 토큰, REST API
서버 확장(Scale-out)	어려움 (세션 공유 필요)	쉬움 (아무 서버나 처리 가능)
서버 부담	상태 저장으로 메모리 부담 ↑	부담 ↓
요청 데이터 크기	작음 (식별자만 전송)	큼 (매번 필요한 정보 다 전송)
장애 대응	서버 죽으면 세션 유실	영향 적음

3-5. 왜 REST는 Stateless를 권장하는가?

1. 확장성(Scalability): 서버를 여러 대로 늘려도(로드밸런싱) 어떤 서버가 요청을 받든 동일하게 처리 가능. ([[nginx 개념 정리]]의 로드밸런싱과 직결됨)
2. 단순함/안정성: 서버가 상태를 안 들고 있으니, 서버가 죽었다 살아나도 문제없음.
3. 독립성: 요청 하나하나가 완결되어 있어 디버깅·캐싱·분산이 쉽다.

3-6. 주의: "Stateless"가 "데이터를 저장 안 한다"는 뜻이 아니다

• DB에 데이터를 저장하는 것은 당연히 한다. (회원 정보, 주문 내역 등은 DB에 영구 저장)
• Stateless가 말하는 건 "클라이언트와의 '대화 맥락(세션 상태)'을 서버 메모리에 들고 있지 않는다" 는 의미다.
• 즉, "이번 요청을 처리하려고 직전 요청을 기억할 필요가 없다" 가 핵심.

---

4. 전체 요약

• REST API: 자원(URI)과 행위(HTTP 메서드)로 설계한, REST 스타일을 따르는 API.
• RESTful 하다: REST의 원칙(자원 기반 URI, 적절한 메서드/상태코드, 무상태 등)을 잘 지켰다는 뜻.
• Stateful: 서버가 이전 상태(맥락)를 기억함. 세션 기반. 확장 어려움.
• Stateless: 서버가 상태를 기억 안 함. 각 요청이 독립적이고 필요한 정보를 모두 담음(JWT 등). 확장 쉬움 → REST가 지향하는 방식.

핵심 한 문장:
"RESTful한 API는 매 요청이 그 자체로 완결되어, 서버가 이전 대화를 기억하지 않아도 처리할 수 있게 설계된 API다."