1. 사건의 발달

저번 프로젝트 진행하면서 URL을 stateless 하게 설계했음.

// 예시 - 자신이 작성한 글 조회
/api/v1/users/{user_id}/boards

그런데 인증, 인가를 검증하는 단계에서 URL의 정보와 JWT 속 정보를 지속적으로 비교 검증해야 번거로운 문제가 발생함.

1. JWT 토큰이 유효한지 확인.
2. URL 속 user_id가 JWT 토큰 속 user_id와 같은지 확인. -> 문제점!
3. user_id를 PK로 하는 사용자가 유효한지 확인.

사용자 정보를 2번 받기 때문에 인증, 인가가 복잡해짐.

→ REST API의 stateless에 대하여 잘못 이해하고 있는 것을 깨달음.

2. Rest API의 stateless란

REST API가 stateless를 추구하는 이유는 다음과 같습니다:

이점	설명
확장성 향상	서버가 클라이언트의 상태를 저장하지 않아 더 많은 요청을 처리할 수 있습니다.
신뢰성 증가	각 요청이 독립적이므로 일부 서버 장애가 전체 시스템에 영향을 미치지 않습니다.
간단한 구현	서버 로직이 단순해져 개발과 유지보수가 용이해집니다.
캐싱 용이	상태 정보가 없어 응답을 더 쉽게 캐시할 수 있습니다.

이러한 이점을 얻기 위해서 stateless 하게 설계하는 것이다.

클라이언트의 context, 세션과 같은 상태 정보를 서버에 저장하지 않겠다는 것.

저번 프로젝트는 Session 대신에 JWT를 사용했던 시점에서 이미 stateless의 조건을 상당수 충족함.

REST API에서 말하는 stateless는 단순히 URL을 stateless하게 설계하라는 말이 아님.

서버만 stateless하게 동작하면 크게 상관없다.

JWT는 Session과 다르게 stateless 하다.

// 예시 - 자신이 작성한 글 조회
/api/v1/users/boards

JWT에 user_id를 담고 있다면 user_id를 URL에 담지 않아도 stateless 하다고 말할 수 있다.

Rest의 특징	설명
Stateless	항상 결과가 무조건 동일해야 한다.
Uniform Interface	데이터가 표준 형식으로 전송될 수 있도록 구성 요소 간 통합 인터페이스를 사용한다.
Cacheable	HTTP를 비롯한 네트워크 프로토콜에서 제공하는 캐싱 기능을 적용할 수 있어야 한다.
Self-descriptiveness	API를 통해 전송되는 내용은 별도 문서 없이 쉽게 이해할 수 있도록 자체 표현 구조를 지녀야 한다.
Client-Server	클라이언트와 서버로 분리되어야하며 서로 의존성이 없어야 한다.
Layered System	요청된 정보를 검색하는데 있어 계층 구조로 분리되어야 한다.

명확하게 정해진 표준은 없지만 암묵적인 규칙은 있다.