WEB이 등장하고 http 1.0의 초판과 기능 개발을 작업하던 로이 필딩(Roy T. Fielding)은 한가지 고민을 하게 됩니다.
"기존 웹을 망가뜨리지 않고 어떻게 http 기능을 증가시킬 수 있을까"
당시 명세가 나오기전부터 이미 폭발적으로 모두가 웹을 사용하고 http 프로토콜을 이용하고 있었기 때문에 하위 버전이 망가지지 않으면서 기능이 추가되는 방법이 필요했고 REST
라는 설계방식을 설명하는 논문이 등장합니다.
클라이언트는 서버에 요청을 보내고 응답 대기
서버가 요청에 대한 결과를 만들어서 응답
서버에는 비즈니스로직, 데이터만을 집어넣고 클라이언트에는 UI만 담당하게 함으로써 서로 더 발전할 수 있었습니다. 꼭 고정적으로 누가 클라이언트고 누가 서버이다기보다는 요청을 보내는 쪽이 클라이언트, 요청을 받고 응답하는 쪽이 서버라고 생각하면 편합니다.
ㄱ. Stateful 이란?
만약 서버가 중간에 바뀐다면 바로 오류가 발생하기 때문에 서버가 클라이언트의 상태를 유지하면서 응답
서버가 바뀌면 안된다는 단점이 있다.
A. 클라이언트 => 제육 주세요 => 서버
B. 클라이언트 <= 몇인분 줄까요? <= 서버 (제육)
C. 클라이언트 => 2인분 주세요 => 서버 (제육 + 2인분)
*C. 만약 여기서 서버가 바뀌었다면?
*D. 클라이언트 <= 뭘 2인분 달라고요? <= 서버
*A. 클라이언트는 다시 결제 과정을 반복해야된다.
D. 클라이언트 <= 제육 2인분 보냅니다 <= 서버
서버가 중간에 바뀌어도 상태 유지자체를 안하기 때문에 서버가 클라이언트의 상태를 보존하지 않고 응답
무한한 서버 증설이 가능하다
A. 클라이언트 => 제육 2인분 주세요 => 서버
*A. 애초에 클라이언트가 필요한 정보를 다 보내기 때문에
서버가 아무리 바뀐들 지장이 없다.
B. 클라이언트 <= 제육 2인분 보냅니다 <= 서버
ㄷ. Stateless의 한계
무상태로 설계 가능한 경우들
로그인이 필요 없는 단순한 서비스 소개 화면
매번 필요한 정보를 클라이언트가 다 보내기 때문에 무겁기도 하다.
상태 유지로 설계해야 될 경우
로그인한 사용자가 로그인했다는 상태를 서버에 유지
보통 브라우저 쿠키, 서버 세션 등 사용해서 상태 유지
그래도 상태 유지는 최소한만 사용
HTTP 헤더에서 캐시와 조건부 요청을 다룰 수 있다. www와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
캐시가 없을 때
캐시 적용
HTTP/1.1 200 OK
Content-Type: image/jpeg
cache-control: max-age=60 //캐시가 유효한 시간
asdjv212... // 이미지 파일 byte
브라우저에서 응답결과를 캐시를 저장한 후 다시 요청할 때 그 유효시간동안 캐시를 조회해서 다시 사용한다.
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..."
}
계층형 시스템구조가 되어야 한다는 의미인데 서버는 클라이언트가 모르게 유연한 구조로 개발될 수 있어야 한다.
서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다.(javascript)
REST는 긴 시간에 걸쳐 진화하는 웹 어플리케이션을 위한 설계방식이다.
HTTP 3.0이 업데이트된다고 했을 때 우리는 브라우저를 그 버전에 맞춰 업데이트해주지 않아도 웹을 이용 가능하다. 또한 HTML 스펙이 새로 추가되었어도 기존 html파일들이 실행 안되는 일 또한 없다. 이런 웹의 발전을 가능하게 한 것은 REST라는 원칙이 있었기 때문에 가능합니다.