REST API 와 HTTP Stateless 에 대한 고찰

wally·2022년 10월 1일
http
2

생각해보기

목록 보기
11/11

1. REST(Representational State Transfer)

Representational 이란?

웹 페이지들의 네트워크를 가상의 상태머신으로 두고 유저가 링크를 선택해서 어플리케이션을 진행시키면 상태 전이가 일어나서 다음 페이지로 가게 된다.

  • 웹 페이지의 네트워크는 하나의 가상 상태머신으로 바라바게 된다면, 한 상태머신 즉 하나의 웹 페이지의 네트워크는 유한한 즉 특정 상태 집합을 갖고 그 중 한 시점에 한 상태를 지니게 된다.
  • 네트워크 내에서 한 웹 페이지를 한 '상태' 로 표현한다.
  • 쉽세 이야기 하자만 서버와 클라이언트와의 통신과정을 바탕으로 상태가 전이되면서 다른 페이지로 넘어가게 된다.
  • 그렇다면 representational 을 어떻게 이해할까?
  • 표현이라고 이해해야한다. 저자의 의도를 유추하자면 통신하는 정보에 대한 집중이 아닌 정보와 표현의 분리를 유도한다.
  • 즉 정보를 뜻하는 자원과 표현하는 양식(Representation) 을 분리한 것이다.
  • REST 통신은 결국 자원에 표현을 써서 자원의 현재 또는 의도된 상태를 포함하고 이 표현을 바탕으로 다른 페이지로 상태전이가 일어나게 된다.
  • 이려한 표현을 나타내기 위해 HTTP 헤더에 Accepst 를 통해 받고자 하는 자원의 표현을 지정할 수 있고 HTTP 메서드를 통해 행위를 세분화할수 있다.

REST 에 대해서 한마디로 정의해 보자

REST 란 하나의 네트워크에서 수많은 웹페이지들이 통신을 하는데 그 통신과정에서 링크를 클릭할 때 정보 자원을 요청하는데 요청 과정에서 정보 자원과 분리된 표현을 선택해 전송하여 상태전이가 시작된다. 그 후 최종적으로 해당 요청을 처리한 응답이 사용자에게 전달되게 된다.

즉 수많은 모듈간의 통신에서 하나의 약속된 REST API 를 통해 상호간의 소통이 가능하게 만들어준다. 여기서 일종의 약속된 표현 양식을 통해 정보자원을 요청하고 이를 기점으로 상태전이가 발생하는 것이다.

URI가 똑같은 이유

  • 로이 필딩은 정보의 내용이나 결과가 바뀔지라도 참조는 정적이어야 한다고 하였다. 즉 REST 는 표현('자원'이 확인하고자 하는 것에 대한 의미)이며 실제 정보가 아니다. 따라서 정보가 변하거나 읽히거나 삭제되더라도 참조는 불변을 유지하는 것이다. 즉 자원의 명시는 변하지 않으며 HTTP Method 를 통해 상세한 표현을 변경할 수 있다.

따라서 CRUD 에서의 URL 은 자원 그자체가 아니라 의미 또는 참조이기 떄문에 변하지 않는다.

hypertext-driven

  • 하이퍼 링크를 타고 페이지를 넘어가듯 링크를 통한 페이지 연결을 일종의 트리구조 형식과 비슷하다. 따라서 URL 또한 계층구조 형식을 가지게 된다.
~/book/12 : 12일에 해당하는 가계부
~/book/12/books/1 : 12일에 해당하는 가계부중 단건 가계부 번호1번

이와 같이 계층구조로 URL  을 만들수 있다.

정리

  • 누구나 쉽게 이해할 수 있게 설명하지 못하면 완벽하게 이해한게 아니다. 하지만 1년전과 비교했을때 이해도가 많이 올라갔기에 1년후에 다시 정리할때는 좀더 쉽게 설명할 수 있을거같다.
  • representational state transfer 는 표현과 상태전이로 설명할 수 있다. 수많은 모듈들이 통신이 가능하게 하기 위해 요청하는 자원과 표현을 분리하여 요청하고 이 요청이 상태전이를 발생 시켜 우리가 원하는 응답을 얻게 하는 것이다.
  • 이러한 표현은 정보 그 자체가 아닌 정보에 대한 참조이기 때문에 불변의 특징을 가지고 이러한 통신이 서비스라는 네트워크 내부에서 수많은 링크를 통해 트리 구조를 가지기 때문에 URL 을 계층구조로 만들 수 있다.

2. REST 구성, 특징

REST 구성

자원(RESOURCE) - URI

  • 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
  • 자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
  • Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.

행위(Verb) - HTTP METHOD

  • HTTP 프로토콜의 Method를 사용한다.
  • HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.

표현(Representations)

  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
  • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
  • (표현에 대한 맞는 의미일까? 잘 모르겠다)

REST 의 특징

1)Uniform(유니폼 인터페이스)

Uniform interface는 URI로 지정한 리소스에 대한조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.

2)Stateless(무상태성)

REST는 무상태성 성격을 갖습니다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API서버는 들어오는 요청만을 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.

3)Cacheable(캐시가능)

REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능합니다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP프로토콜 표준에서 사용하는 LAST-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.

4)Self - descriptiveness(자체표현 구조)

REST의 또 다른 큰 특징 중 하나는 REST API메세지만 보고도 이를 쉽게 이해 할 수있는 자체 표현 구조로 되어 잇다는 것입니다.

5)Client -Server구조

REST 서버는 API제공, 클라이언트는 사용자 인증이나 컨텍스트(세션,로그인 정보)등을 직접 관리하는 구조로 각각의 역활이확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들기게 됩니다.

6)계층형 구조

REST 서버는 다중 계층으로 구성될 수 있으며, 보안로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수있게 합니다.

  • 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
  • HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

REST API 규칙

  • 즉 URI 는 정보의 자원만 표현해야 한다. 따라서 시소스 명은 동사보다 명사를 사용한다.
 GET /members/delete/1 ( 행위가 자원 명시에 포함되면 안된다. 행위는 HTTP Method 를 통해 분리하자 )
  • 슬래시는 계층구조를 나타내는데 사용하자
    http://restapi.example.com/houses/apartments
    http://restapi.example.com/animals/mammals/whales

3. Stateless 란?

  • REST API 는 Stateless 라고 표현하는데 정확하게 이해하고 해당 용어를 사용하는 것일까? 한번 고민해 보자

Stateful

stateful : server side에 client와 server의 동작, 상태정보를 저장하는 형태, 세션 상태에 기반하여 server의 응답이 달라짐

Stateless

stateless : server side에 client와 server의 동작, 상태정보를 저장하지 않는 형태, server의 응답이 client와의 세션 상태와 독립적임
장점 : 서버가 client정보를 저장관리 하지 않으므로 Scaling이 자유로움

왜 REST API 는 Stateless 해야할까? - HTTP가 바로 Stateless 하다!

HTTP

  • 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜
  • HTTP 는 비연결성(Connectionless)과 무상태(Stateless)라는 특성을 가진다.

비연결성(Connectionless)

  • 비연결성이란 클라이언트가 요청(request)을 하고, 서버가 해당 요청에 적합한 응답(response)를 하게 되면 바로 연결을 끊는 성질을 의미

무상태(Stateless)

  • 비연결적인 특성으로 연결이 해제됨과 동시에 서버와 클라이언트는 클라이언트가 이전에 요청한 결과에 대해서 잊어버리게 됩니다. 즉, 클라이언트가 이전 요청과 같은 데이터를 원한다고 하더라도 다시 서버에 연결을 하여 동일한 요청을 시도해야만 합니다.

왜 connectionless 하고 stateless 한가?

  • 독립적인 쌍의 요청과 응답을 처리함으로 단순하고, 상태를 저장해야 하는 서버의 부담을 감소시킬 수 있다

한계점 - 인증인가 - 쿠키와 세션으로 극복

  • 쿠키는 브라우저에 있는 저장소이다. 헤더에 해당 값을 보내면 되기에 상태를 유지하게 된다.
  • 세션은 서버 저장소를 사용하는 것으로 서버 값을 가지게 되므로 상태를 가지게 된다. 해당 서버와만 통신이 가능하기에 scale out 이 안돼(가능하지만 복잡)

왜 REST API 는 Stateless 해야할까? - 확장가능성

  • 로이 필딩은 왜 REST 를 정의할 떄 Stateless 제약조건을 포함하였을까?
  • stateless 가 시스템 확장에 더 유리하기 때문이다.
  • stateless 한 경우 사용 가능한 모든 인스턴스를 활용할 수 있다. 또한 언제든 쉽게 새 인스턴스를 추가할 수 있다. 또한 인스턴스가 실패하면 간단히 다시 시작하거나 새로 추가하면 된다.
  • session 을 사용한 경우 동일 인스턴스만 사용할 수 있게 로드 밸런서 조작이 필요하다. - 복잡성을 올린다.

session 이 RESTfullness 를 위반하는가?

  • 세션은 서버에 저장된다

  • RESTfull 제약 조건은 세션이 클라이언트에 의해서만 저장되어야 함을 나타낸다.

  • 따라서 세션은 RESTfullness 를 위반한다.

  • 하지만 stateless 를 포기하고 세션을 사용함으로서 얻는 이점은 분명하다.(금융 서비스의 경우 보안을 위한 포기)

정리

  • rest http stateless 이 모든 것에는 이유가 있다.
  • 무엇보다 확장가능성과 개발의 단순함을 지향하는 것 같다.
  • 하지만 반드시 원칙들이 지켜져야 하는 것은 아니다. 서비스 환경에 따라 일부 원칙들을 포기하고 stateful 한 서비스 사용도 가능하다.

참고사이트

https://shoark7.github.io/programming/knowledge/what-is-rest
https://meetup.toast.com/posts/92
https://shyvana.tistory.com/7
https://www.charlezz.com/?p=44767
https://www.baeldung.com/cs/rest-vs-http
https://www.baeldung.com/cs/rest-sessions

profile
wally
클린코드 지향
이전 포스트

soft delete 와 hard delete 비교

0개의 댓글