REST에 대해서 다시 이해해보자 - 이해 한지 다시 생각해보자

개발자와 이야기 하다 보면 특히나 웹 개발자들은 상식으로 알고 있는

REST라는 개념이 있는데 알고 있으면서도 정리가 안되거나 명확하게 설명이 안되는거

같아 이번 기회에 정리해본다.

 

물론 필자도 맨날 이해했다고 생각하고 다 틀리기 때문에

아 이렇게 생각하는 개발자가 있구나, 내 생각이랑 틀리면

답글 남겨주시면 고민 더해서 추가적으로 보안 해오겠다.

REST는 언제 시작 되었는가

로이 필딩(Roy Fielding)은 2000년에 UC 어바인에서

"Architectural Styles and the Design of Network-based Software Architectures “ 라는 논문에서 정리한건데

소프트웨어를 디자인하는 아키텍처 론에 대한 이야기다.

 

여기서 REST라는 개념이 등장한다. 벌써 20년이나 지난 개념이라는게 차츰 놀라울 뿐이다.

세상은 천재에 의해 발전한다는 것이 또 한번 느껴진다.

REST(Representational State Transfer)

직역하면 현재 상태의 대한 전송 이렇게 이야기 할 수 있는데

중요한 점은 현재 자원의 상태의 대한 전송 이라는 이야기이다.

 

여기서 종종 Full한 개념에 얽매여 이 자체에 대한 개념을 잊어버리곤 하는데

REST는 규칙이 아닌 조건이다.

 

정리하면 이 조건의 만족한다면 어떤 형태로 만들던 REST하다고 이야기할 수 있으며

우리가 흔히 사용하는 메이저한 프레임워크들은 객체(Data)를 송수신하는 과정에서

이러한 REST를 사용하다록 유도한다.

 

왜냐하면 프레임워크 라는게 결국 어떤 자주 사용되는 형태를 쉽고 빠르게 쓸 수 있도록

정의 해두고 당겨다가 쓸 수 있게 해주는 것이기 때문인데 REST는 아키텍처 설계에 대한

제약 조건에 대한 개념이기 때문에 해당 개념을 빼고 쓴다는 것은 상당히 역행 적인

행동이라고 볼 수 밖에 없다.

 

(물론 아 모르겠고 , 쉽게 할래 하면 적용이 안되긴 한다.)

그래서 조건이란게?

REST 아키텍처에 적용되는 6가지 제한 조건

다음 제한 조건을 준수하는 한 개별 컴포넌트는 자유롭게 구현할 수 있다.

 

1. 인터페이스 일관성 (Uniform Interface)

• 개념: 시스템 내 모든 인터페이스는 일관된 형태로 제공되어야 합니다.
• 의미: 자원의 상태가 특정 상황에 따라 임의로 변동되거나 소실되어서는 안 된다. 즉, 자원에 대한 접근과 조작 방식이 명확하고 일관되게 유지되어야 한다. 예를 들어 값이 특정 상태가 됬다고 지 맘대로 사라지면 데이터 보내던거 안보내면 REST하지 않다는 뜻임

2. 무상태(Stateless)

• 개념: 각 요청 간 클라이언트의 상태(콘텍스트)는 서버에 저장되지 않아야 합니다.
• 의미: HTTP와 같이 무상태성을 기본 원칙으로 하는 프로토콜은 클라이언트와 서버의 독립성을 보장합니다.
  • 예시: 각 HTTP 요청은 독립적으로 처리되며, 서버는 이전 요청의 상태 정보를 기억하지 않는다는 것이 기본이라서 HTTP를 쓰면 기본적으로 무상태가 됨
  • 참고: 널널한 개발자 선생님 인프런에서 비슷한 이야기하다가 이런 이유가 기반되어서 JS가 되었다는 이야가를 했던게 기억에 있네

3. 캐시 처리 가능(Cacheable)

• 개념: 클라이언트는 서버의 응답을 캐싱할 수 있어야 합니다.
• 의미: 솔직히 요즘 프론트 프레임워크 다쓰는데 이런 캐싱개념 안쓴다? 너는 프론트하지마라. 라는 쓴소리가 들어올지도.. 

4. 계층화(Layered System)

• 개념: 클라이언트는 실제 대상 서버와 직접 통신하는지, 또는 중간 서버(예: 로드 밸런서, 공유 캐시 서버)를 통해 통신하는지 알 수 없어야 합니다.
• 의미: 중간 서버는 로드 밸런싱이나 캐싱 기능을 제공하여 전체 시스템의 확장성과 안정성을 높여줍니다.
  • 예시: 웹 서버 뒤에 WAS(API 서버)를 두는 구성은 이러한 계층화 원칙을 두고 만드는건데 보통 다 이렇게하니까 이미 적용되어 있을 것임
  • 추가: 과거에는 SSR(서버 사이드 렌더링)이 기본 개념으로 적용되서 이런 개념이 있지않을까? 20년전이니까 라는 생각을 한다.

5. Code on demand (Optional)

• 개념: 서버가 자바 애플릿이나 자바스크립트 등의 실행 코드를 클라이언트로 전송하여 기능을 확장할 수 있습니다.
• 의미: 이 기능은 선택사항(optional)으로, 모든 RESTful 시스템에서 반드시 구현해야 하는 것은 아닙니다.
  • 활용: 클라이언트 측에서 동적으로 기능을 추가하거나 변경할 수 있게 함으로써, 클라이언트의 처리 능력을 보완합니다. 그냥 동적 소스가 추가되느냐 인데 요즘은 안하는게 더 이상하니까 예전 개념이라고 봐도됨

6. 클라이언트/서버 구조

• 개념: 클라이언트와 서버의 역할을 명확하게 분리하여, 각 부분이 독립적으로 개선될 수 있도록 합니다.
• 의미: 이러한 분리 덕분에 시스템 전체가 단순화되고, 모듈화가 촉진되며, 결과적으로 유지보수성과 확장성이 향상됩니다 이 원칙은 MSA(마이크로서비스 아키텍처) 등 최신 설계 패러다임이랑도 맞음 역시 천재임

(참조 : 나무위키 - https://ko.wikipedia.org/wiki/REST )

 

다른 블로그들을 보다 보면 이 개념이 아닌 어떤 정형화된 규칙에 대한 이야기를 한다.

예를 들어 원래 논문에 포함된 예시중 있는 URL을 보고

URL 명명 규칙이나 URL에 들어가는 사용 용어 대해 깊게 고민하는데

 

물론 틀린 말은 아니지만 , 저 조건에서 이야기하는 일관성을 보장하기 위한

이야기로써 우리는 이렇게 하자 라는게 통용되는 것이지 그것이 정답이다. 라고 하는 것은

REST에 대해 원론적인 이야기를 할때는 크게 의미 없다고 생각한다.

 

이것을 예로 이야기하자면 REST에 대한 본래 의미는 자원에 대한 구성 요소를 말하며

자원이 어디에 있는 지를 알아야 쓸 거 아니냐 ! 이거 통용 하자

 

그래서 Resource에 대한 Identifier 에 대해 이야기하고 URI 가 나오고 흔히 사용하는 URL이라는

개념을 예로 설명을 하고 있는 것인데 URL 쓸데 어떻게 쓰라던데요?

라고 하면 맞는 말이지만, 이를 이해했다고 말하는 것은 어려움이 있다.

 

결국 이야기하고 싶은 것은 REST는 꽤나 러프한 조건 내에서

만족한다면 자유롭게 내부적인 커스터 마이징이 가능하다는 것을 이해하자는

이야기이다.

 

HTTP 로 생각해보자

나같은 백엔드개발자들은 거의 주로 HTT 에 대한 프로토콜을 사용한다. (HTTP)

그래서 HTTP에서 제공하는 GET , POST , PUT , Delete 이외에도 몇개 더있는데

여기서 자원의 상태를 표현하는 4가지를 사용하고 이를 C,R,U,D로 매핑하여

개념을 생각한다.

 

왜 이것을 정형화가 되냐 라고 한다면 너무 단순하게 HTTP가 가진 심플함때문인데

이를 CRUD가 여기에 매핑 되는 것이라고 이해하는 것이 아니라

 

HTTP를 사용할때는 이렇게 사용하는 것이다.

라고 이해하는 것이 더 옳바른 이해라고 생각된다.

 

결국 정리하면 구성요소는 다음 3가지라고 말할 수 있다.

 

Resource, Representation, Identifier

• 리소스
  • 엔티티 집합의 개념적 매핑.
  • 정보의 추상화.
  • 세상의 무엇이든 리소스가 될 수 있다.
  • 하나의 리소스는 여러 식별자를 가질 수 있음.
• 식별자
  • 리소스에 매핑된 일종의 이름.
  • URI.
  • 하나의 식별자는 하나의 리소스에만 매핑될 수 있음.
• 표현(representation)
  • 서버가 응답으로 보내주는 것은 리소스가 아니라, 리소스의 표현이다.
  • 표현에는 데이터와 메타데이터가 들어있다.
  • 서버는 클라이언트가 보낸 정보를 보고 클라이언트에 맞는 형태로 리소스에 근거한 표현을 돌려준다.
  • 클라이언트는 메타데이터를 보고 데이터를 어떻게 해석할지를 알게 된다.

이렇게가 구성요소가 된다는 것이다.

 

근데 이걸보고 블로그에다가 REST 구성요소에다가 HTTP 메서드를 넣어두면

공부하는 개발 지망생 들이나 블로그 보고 공부했던 주니어 개발자들이

혼동이 오는 것은 당연하다고 보여진다.

 

참고로

어떤 멋진형님이 번역해서 요약까지 해두심 참고하시면 좋을듯

https://johngrib.github.io/wiki/clipping/roy-fielding/rest-paper/ 

(요약) Architectural Styles and the Design of Network-based Software Architectures by Roy Thomas Fielding, 2000