REpresentational State Transfer

WEB이 등장하고 http 1.0의 초판과 기능 개발을 작업하던 로이 필딩(Roy T. Fielding)은 한가지 고민을 하게 됩니다.

"기존 웹을 망가뜨리지 않고 어떻게 http 기능을 증가시킬 수 있을까"

당시 명세가 나오기전부터 이미 폭발적으로 모두가 웹을 사용하고 http 프로토콜을 이용하고 있었기 때문에 하위 버전이 망가지지 않으면서 기능이 추가되는 방법이 필요했고 REST라는 설계방식을 설명하는 논문이 등장합니다.

REST를 구성하는 스타일

1) Client - Server

클라이언트는 서버에 요청을 보내고 응답 대기
서버가 요청에 대한 결과를 만들어서 응답

서버에는 비즈니스로직, 데이터만을 집어넣고 클라이언트에는 UI만 담당하게 함으로써 서로 더 발전할 수 있었습니다. 꼭 고정적으로 누가 클라이언트고 누가 서버이다기보다는 요청을 보내는 쪽이 클라이언트, 요청을 받고 응답하는 쪽이 서버라고 생각하면 편합니다.

2) Stateless

ㄱ. Stateful 이란?

만약 서버가 중간에 바뀐다면 바로 오류가 발생하기 때문에 서버가 클라이언트의 상태를 유지하면서 응답

서버가 바뀌면 안된다는 단점이 있다.

A. 클라이언트  => 제육 주세요 => 서버
B. 클라이언트  <= 몇인분 줄까요? <= 서버 (제육)
C. 클라이언트  => 2인분 주세요 => 서버 (제육 + 2인분)
    *C. 만약 여기서 서버가 바뀌었다면?
    *D. 클라이언트  <= 뭘 2인분 달라고요? <= 서버
    *A. 클라이언트는 다시 결제 과정을 반복해야된다.

D. 클라이언트  <= 제육 2인분 보냅니다 <= 서버

서버가 중간에 바뀌어도 상태 유지자체를 안하기 때문에 서버가 클라이언트의 상태를 보존하지 않고 응답

무한한 서버 증설이 가능하다

A. 클라이언트  => 제육 2인분 주세요 => 서버
    *A. 애초에 클라이언트가 필요한 정보를 다 보내기 때문에
    서버가 아무리 바뀐들 지장이 없다.

B. 클라이언트  <= 제육 2인분 보냅니다 <= 서버

ㄷ. Stateless의 한계

• 무상태로 설계 가능한 경우들

• 로그인이 필요 없는 단순한 서비스 소개 화면

• 매번 필요한 정보를 클라이언트가 다 보내기 때문에 무겁기도 하다.

• 상태 유지로 설계해야 될 경우

• 로그인한 사용자가 로그인했다는 상태를 서버에 유지

• 보통 브라우저 쿠키, 서버 세션 등 사용해서 상태 유지

• 그래도 상태 유지는 최소한만 사용

3) Cache

HTTP 헤더에서 캐시와 조건부 요청을 다룰 수 있다. www와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.

1. 캐시가 없을 때

   • 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드받아야 된다.
   • 인터넷 네트워크는 매우 느리고 비싸다
   • 느린 사용자 경험

2. 캐시 적용

     HTTP/1.1 200 OK
     Content-Type: image/jpeg
     cache-control: max-age=60 //캐시가 유효한 시간
   
     asdjv212... // 이미지 파일 byte

   브라우저에서 응답결과를 캐시를 저장한 후 다시 요청할 때 그 유효시간동안 캐시를 조회해서 다시 사용한다.

4) Uniform Interface

Resource(모든 자원, uri, img, txt 등등)에 대한 요청을 통일되게 설계하는 아키텍처 스타일

• identification of resources : 리소스가 uri로 식별되게 해라

• manipuliation of resource through representation: HTTP메소드의 get,post,delete 등 represntation 전송을 통해 리소스 조작 가능해야 한다.

• self-descriptive message: 어떤 메세지든 스스로 설명해야 한다.

  HTTP/1.1 200 OK
  Host: www.example.org
  Content-Type: application/json-patch+json
  
  [ { "op": "remove", "path": "/a/b/c" } ]

• Hypermedia as the engine of application state(HATEOAS): 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.

  HTTP/1.1 200 OK
  Content-Type: application/json
  Link: </articles/1>; rel="previous",
              </articles/3>; rel="next";
  
  {
      "title": "The second article",
      "contents": "blah blah..."
  }

5) Layered Sysytem

계층형 시스템구조가 되어야 한다는 의미인데 서버는 클라이언트가 모르게 유연한 구조로 개발될 수 있어야 한다.

6) Code-on-Demand(optional)

서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다.(javascript)

결론

REST는 긴 시간에 걸쳐 진화하는 웹 어플리케이션을 위한 설계방식이다.

• HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시
• HTTP Method(POST, GET, PUT, DELETE)를 통해
• 해당 자원(URI)에 대한 CRUD Operation을 적용
• REST의 6가지 원칙을 준수하며 설계

HTTP 3.0이 업데이트된다고 했을 때 우리는 브라우저를 그 버전에 맞춰 업데이트해주지 않아도 웹을 이용 가능하다. 또한 HTML 스펙이 새로 추가되었어도 기존 html파일들이 실행 안되는 일 또한 없다. 이런 웹의 발전을 가능하게 한 것은 REST라는 원칙이 있었기 때문에 가능합니다.