State in REST API

API에서 말하는 state

API 문맥에서 state라는 단어는 두 가지 의미로 자주 쓰인다.

• 리소스의 현재 상태
• 서버가 클라이언트의 이전 상호작용을 기억하는가

이 둘을 섞어서 이해하면 REST 개념이 쉽게 흐려진다.

리소스의 상태

리소스 상태는 특정 시점에 서버가 가진 데이터 스냅샷이다. 예를 들어 주문 리소스라면 다음 정보가 상태에 해당한다.

• 주문 번호
• 현재 상태값 (CREATED, PAID, SHIPPED)
• 금액, 품목, 생성 시각

클라이언트가 GET /orders/123을 호출했을 때 받는 응답은 그 리소스의 현재 표현이다.

Stateful과 Stateless

이와 별도로 stateful/stateless는 서버가 클라이언트의 대화 맥락을 저장하느냐를 말한다.

Stateless

• 각 요청이 독립적이다.
• 서버는 이전 요청의 문맥을 기억하지 않는다.
• 인증, 파라미터, 버전 정보 등 필요한 데이터가 매 요청에 포함된다.

REST는 기본적으로 stateless를 지향한다.

Stateful

• 서버가 세션이나 대화 맥락을 기억한다.
• 이전 단계가 완료됐는지에 따라 현재 요청이 해석된다.
• 웹 세션, 다단계 폼, 서버 측 장바구니가 대표 사례다.

REST에서 state를 어떻게 봐야 하나

REST에서 중요한 것은 서버가 클라이언트 세션을 기억하지 않는다는 점이지, 리소스 상태가 없다는 뜻이 아니다. 오히려 REST는 리소스 상태를 명확히 다루는 방식이다.

즉:

• 리소스 상태는 반드시 존재한다.
• 클라이언트 대화 상태는 서버에 남기지 않는 편이 REST에 가깝다.

HATEOAS와 상태 전이

HATEOAS는 클라이언트가 다음에 가능한 행동을 응답 안의 링크로 알 수 있어야 한다는 개념이다.

예를 들어 주문 상태가 CREATED일 때 응답에 다음 링크가 포함될 수 있다.

• 결제
• 취소

이 경우 응답은 단순 데이터만 전달하는 것이 아니라, 현재 상태에서 어떤 전이가 가능한지도 함께 설명한다.

다만 실무에서는 HATEOAS를 완전하게 구현하는 경우가 드물다. 많은 시스템이 문서와 프런트엔드 로직으로 상태 전이를 관리한다.

실무에서 유용한 구분

• 리소스 상태: 주문 상태, 결제 상태, 재고 상태
• 서버 세션 상태: 로그인 세션, 장바구니, 다단계 입력 흐름
• 워크플로 상태 전이: 현재 상태에서 어떤 행동이 허용되는가

이 세 축을 분리해서 보면 REST 설계가 훨씬 선명해진다.

정리

REST API에서 state를 이해할 때는 리소스 상태와 서버 세션 상태를 구분해야 한다. REST는 리소스 상태를 다루는 아키텍처이지만, 클라이언트와의 대화 맥락은 서버에 남기지 않는 쪽을 지향한다.