REST - 논문(요약) 훑어보기
연재 목록
- REST - 긴 여정의 시작
- REST - HTML Form에서 GET/POST만 지원하는 이유
- REST - 논문(요약) 훑어보기
- REST - REST 좋아하시네
- REST - Roy가 입을 열다
- REST - 당신이 만든 건 REST가 아니지만 괜찮아
- REST - 논문 읽기(To Do)
논문
REST의 사전적인 의미부터 알아보자.
‘바쁜 개발자들을 위한 REST 논문 요약’을 요약 + WhatIsRest.com + 지난 며칠간 블로그와 댓글을 뒤져가며 얻은 지식 + 내 생각을 적어보려고 한다.
REST 제약 조건
논문에서는 아무것도 없는 웹 스타일에서 시작해, 제약 조건을 하나씩 추가해 나가며 REST 스타일을 유도해 나가는 과정을 통해 REST를 설명한다.
- Starting with the Null Style
- Client-Server
- Stateless
- Cache
- Uniform Interface
- Layered System
- Code-On-Demand
각 제약 조건을 취하면서 발생하는 trade-off도 언급하고 있으나 여기서는 넘어가기로 한다.
Client-Server
보통 생각하는 서버-클라이언트를 의미.
여기서 의문이 들었던 게, Client-Server라는 게 과연 제약조건이라고 할 수 있는 건가? 그러니까, 제약 조건을 어기는 게 과연 가능한가?
이 제약조건은 클라이언트와 서버의 역할을 명확하게 구분한다 정도로 생각하면 될 것 같다.
서로의 관심사를 분리하여 각각의 로직의 독립적인 진화를 지원해야 한다(중요).
Stateless
모든 요청은 필요한 모든 정보를 담고 있어야한다.
요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 확보된다.
API 문외한 입장에서 가장 이해가 안 됐던 부분 중 하나였다. 인증을 위해 쿠키를 심고 세션에서 필요한 정보를 가져오는 경우, 이는 stateless인가 아닌가?
- 정답 : Session 정보 활용한다면 stateless가 아니다
REST에서는 각각의 요청에 서버가 필요한 정보가 모두 담겨야 한다.
Cache
모든 서버 응답은 캐시 가능한 지 그렇지 않은 지 알 수 있어야 한다.
캐시를 고려한 설계가 필요하다.
Uniform Interface
구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야한다.
- 이것만으로는 무슨 말인지 모르겠다
WhatIsREST.com의 내용을 구글 번역으로 돌려보면
소비자는 많은 소비자와 서비스에서 표준화 된 방법, 미디어 유형 및 공통 리소스 식별자 구문을 통해 서비스 기능에 액세스합니다라고 나오는데,
미디어 유형이나 리소스 식별자 등을 의미하는 문법이 구성요소나 호환 시스템 간 동일해야 한다는 의미
균일한 인터페이스가 필요한 이유는
- 서버 입장에선 어떤 클라이언트든 상관없이(내가 보내주는 것을 이해할 수 있을까 걱정없이) 표준에 의한 응답을 해줄 수 있고
- 클라이언트 입장에선 hypertext를 통해 다음 상태로의 이동을 해야하는데, 표준화된 방식을 통해 해당 서버의 특성을 알 필요가 없어진다
- 서로의 특성을 알지 못해도 커뮤니케이션이 가능할 수 있어야, 각각 독립적으로 진화할 수 있는 유연한 시스템이 만들어진다
REST는 네가지 Interface 제약조건으로 정의된다
네가지 Interface 제약조건에서 언급된 내용을 구글 번역으로 좀 더 상세히 살펴보자.
- 이 자원의 추상적 정의는 웹 아키텍처의 핵심 기능을 가능하게 합니다
- 유형이나 구현에 따라 인위적으로 구별하지 않고 많은 정보 소스를 포괄함으로써 보편성을 제공합니다
- 표현에 대한 참조의 늦은 바인딩을 허용하여 요청의 특성에 따라 내용 협상을 수행 할 수 있습니다
- 저자는 개념의 단수 표현보다는 개념을 참조 할 수 있으므로 표현이 바뀔 때마다 기존의 모든 링크를 변경할 필요가 없습니다
1. identification of resources
리소스를 식별하는 방법이 동일해야 한다. 우리는 보통 URI를 쓰기 때문에 어쩐지 당연한 말처럼 느껴진다.
2. manipulation of resources through representation
representation의 개념은 이응준님 블로그에서 다루고 있다.
리소스의 표현계층(representation)을 리소스의 식별자(URL)로부터 분리한 것은 REST에서 아주 주요한 관점이다.
RESTful 응용 프로그램은 동일한 URI에서 동일한 자원의 표현을 둘 이상 지원할 수 있다.
3. self-descriptive messages
요청이나 응답 메시지에는 이를 이해하기 위한 모든 정보가 포함되어야 한다.
4. hypermedia as the engine of application state
줄여서 HATEOAS라고도 하지만 REST를 사랑하는 이들은 종종 이렇게 줄여부르는 걸 싫어하기도 한다(똑똑하고 재수없게 보이려면 ‘HATEOAS라고 줄여 부르는 건 바보같다’라고 말하면 된다).
훗날 블로그에서 Roy는 이 부분을 가장 강조하는데, 어쩌면 사람들이 가장 안 지키고 있기 때문일 지도 모르다는 생각을 했다.
그리고 이를 언급할 때 주로 hypertext라는 표현을 사용한다.
논문에서 hypermedia라고 한 것은 단지 text가 아닌 매체를 고려했기 때문이고,
일반적인 API에서는 거의 hypertext라고 표현하면 된다.
음? 우리가 HTML 페이지에서 맨날 보는 그 hypertext라는 용어가 맞나?
맞다. 제시된 hypertext 위에서 application 상태를 변경하는 주체가 client가 되어야 한다는 게 핵심이다.
조대협님의 블로그에는 HTTP Response에 다음 Action이나 관계되는 리소스에 대한 HTTP Link를 함께 리턴하는 것이라고 언급이 되어 있다.
- 뭔가…이상한데…틀렸다고 하기는 뭣 하지만 온전히 이해가 되는 문장은 또 아니다. 다른 사람의 의견을 더 들어보자
- 다들 혼란스러워하는 것 같은데 직접 로이 필딩에게 물어보지 그래?
- 로이의 문장은 명확하고, 모호하지도 않으니 그냥 읽어보길 바란다
- 로이가 HTTP 표준의 기여자라는 것을 잘 생각해보자
- 이 논문의 주제는 WWW가 잘 동작하고 확장성도 좋고, REST가 WWW 아키텍쳐 위에서 동작한다면, 이 역시 잘 동작하고 확장성이 좋다는 것이다
- 4가지의 제약 조건은 결국 URI를 사용해서 MIME-typed 문서를 GET/PUT 등으로 전송하는 것 + HATEOAS
- WWW := URI + HTTP + MIME + Hypermedia
- Hypermedia라는 건 hypertext를 확장한 개념
- 좀 더 정확하게 쓰자면, HATEOAS := hypermedia documents as the state of state
- 로이의 배경을 생각하면 그는, 하이퍼링크가 없는 HTML 도큐먼트를 상상조차 못할 인물이다
- 그가 언급한 Hypermedia란 문서 자체를 의미한다
- 로이는 HTTP통신에 Link header를 넣어도 여전히 RESTful 할 수 있지만, 합당한 이유가 있어야 한다고 했다
- 역주) 헤더에 넣으면 이를 처리할 수 없는 클라이언트도 있을 수 있기 때문에..라고 했는데 당시에는 LINK가 정식 표준이 아닌 때였기 때문인 것 같음
- HATEOAS를 정확히 구현한 것은 문서안에 있는 링크다
- HATEOAS라는 다음 상태 변경을 위한 링크(form 링크 등)를 제공해야 한다는 것
이 문서도 좀 제멋대로 해석한 부분이 있는데, Roy는 단지 HTTP만을 염두에 둔 게 아니다. HTTP이거나 HTML 문서이거나 그런 게 중요한 게 아니다.
HATEOAS라는 걸 응답에 다음 액션에 관한 링크를 전달하는 것 정도로 생각하면 안 된다.
- 응답에 링크를 주렁주렁 달고 다니면 HATEOAS가 되는가? NO!
- 서버는 Hypermedia를 통해 다음 액션에 대한 선택지를 클라이언트에게 줘야한다
- 클라이언트는 서버의 독자적인 진화에 영향을 받아선 안 되며, 서버 상의 구현에 의존하면 안 된다
결국 HATETOAS의 목적은 (서버-클라이언트 간 의존성을 분리해야만 가능한) 독자적인 진화와 확장을 보조하는 것이며, hypermedia는 그 목적을 이루는 데 기여해야 한다
Layered System
클라이언트든 서버든 미들웨어 구성요소를 추가할 수 있는 구조.
하지만 Client-Server 사이에선 그 구성요소가 추가되는지, 다른 서비스와 추가로 통신하는 지 여부는 관심없다.
서버와 클라이언트 간 상호 작용을 일관성있게 유지해야 한다.
Code-On-Demand (Optional)
서버가 네트워크를 통해 클라이언트에 프로그램을 전달하면 그 프로그램이 클라이언트에서 실행될 수 있어야한다. (Java applet이나 Javascript 같은 것을 말함).
다만 이 제약조건은 필수는 아니다.
thanks to
이응준님의 블로그에서 많은 영감을 얻음