REST resource, representation
REST의 resource, representation은 무엇인가
Roy T Fielding의 논문에 대한 의역과 주관적인 해석
TL;DR
5.2 REST Architectural Elements
REST style이란 distributed hypermedia system의 구조적 원소들의 추상화이다.
- hypermedia system : 텍스트를 동영상, 음성 파일과 연결하는 시스템
- distributed hypermedia system: web
- architectural element : REST를 구성하는 요소(개념)들
REST는 component들의 역할, component들 사이의 통신에 대한 제약, 중요한 data elements에 대한 component들의 해석에 집중하기 위해 그것들의 구현체와 protocol에 대해서는 신경 쓰지 않는다.
component : web에서 데이터를 주고받는 주체 (server, client, gateway, proxy)
5.2.1 Data Elements
REST의 핵심 특징(key aspect)는 architecture의 data element의 종류(nature)와 상태(state)이다.
Link가 클릭되면 정보는 그것이 저장된 장소에서 사용될 장소(보통 human reader)까지 이동해야 한다.
분산 하이퍼미디어 구조(web)은 오직 세 가지의 선택사항(options)을 가지고 각 선택사항에는 장단점이 존재한다.
- 서버에서 rendering한 뒤 fixed-format 형태의 데이터를 클라이언트에게 전달.
- 장점 : 전통적인 client-server 방식이다. 통신에 사용되는 자료구조, 클라이언트 구현이 어떻게 되었는지 추측하기 어렵게 만든다.
- 단점 : 클라이언트의 기능이 제한되고 대부분의 processing load가 서버에 집중되어 확장성(scalability) 문제 발생.
- data를 rendering 엔진과 포장(encapsulate)하여 클라이언트에게 전달. 이를 mobile object style 이라고 한다.
- 장점 : unique rendering engine을 이용해 데이터를 처리(해석)하기 때문에 정보(information)을 숨길 수 있다.
- 단점 : 클라이언트의 기능이 제한되고 전송되는 데이터의 양이 크게 증가한다. (데이터 뿐만 아니라 렌더링 엔진까지 전달하기 때문)
- raw data와 그것의 data type을 설명하는 metadata를 같이 전송하여 클라이언트가 rendering engine을 선택하는 방식.
- 장점: 서버의 구현이 간단하고 확장 가능하며 전송되는 데이터의 크기를 줄일 수 있다.
- 단점: 정보를 숨길 수 없다. 서버와 클라이언트 모두 동일한 data type을 이해해야 한다. (인코딩/디코딩 방식이 일치해야하는 문제랑 비슷하다)
REST는 세 가지 방식을 혼합한 것이다. REST는 metadata를 통해 data type에 대한 이해를 공유하는 것에 집중하며 일관된 interface를 위해 노출의 범위를 제한한다.
REST component들은 resource에 대한 representation을 전송하며 소통(communication)한다. 각 representation은 정해진 format을 따르며 이 format은 recipient가 원하는 것과 resource의 종류 또는 recipient의 능력(capability)에 따라 동적으로 선택된다.
Representation이 raw source와 동일한 format이거나 source로부터 파생되었든 아니든, representation은 interface에 의해 숨겨진다. 요청에 포함된(encapsulated) 렌더링 엔진(예를 들면 Java)으로 해석이 가능한 명령어들로 구성된 representation을 보내는 방식으로 mobile object style의 장점을 가져갈 수 있다.
REST의 data elements는 다음과 같이 요약된다.
| Data Elements | Modern Web Examples |
|---|---|
| resource | 하이퍼링크에 의해 의도된 개념적인 목표(target) |
| resource identifier(resource를 식별하는 방법) | URL, URN |
| representation | HTML 문서, 이미지, 동영상 |
| representation metadata | media type, last-modified time |
| resource metadata | source link, alternates, vary |
| control data | if-modified-since, cache-control |
5.2.1.1 Resources and Resource Identifiers
REST에서 정보(information)에 대응되는 핵심 개념은 resource이다. 이름이 붙여질수 있는 모든 정보는 resource가 될 수 있다. 예를 들면 문서, 이미지 또는 오늘 서울의 날씨와 같은 일시적인 서비스, 다른 resource의 묶음, 실재하는 객체(예를 들면 한 명의 사람) 등이 resource가 될 수 있다. 즉, 하이퍼링크의 타겟이 되는 모든 개념은 resource의 정의에 부합해야 한다.
Resource란 entities로 이루어진 집합으로의 개념적인 대응이지 특정 시점에서의 구체적인 entity가 아니다.
좀 더 구체적으로 표현하자면, resource R은 시간에 따라 변하는 membership function Mʀ(t) 이다. 이 함수는 시간 t에서 entities 또는 values 집합으로의 대응이다.
여기서의 value는 resource representation 또는 resource identifier일 수 있다. Resource는 공집합으로 대응될 수도 있다. 이것은 참조(references)가 개념을 위해 만들어질 수 있도록 허락한다. 그 개념의 존재 여부를 알기 전에도 참조는 생성될 수 있다. 이런 개념은 웹이 등장하기 전 대부분의 hypertext system과는 맞지 않는 개념이였다.
Resource는 한 번 생성되면 그 내용(value set/entity set)이 변하지 않는 경우도 있고 시간에 따라 자주 변할 수도 있다. Resource가 static이기 위해 필요한 조건은 mapping의 의미(semantic)이다. Resource와 다른 resource를 구별하는 것은 semantic이기 때문이다.
resource
Resource는 이름을 붙일 수 있는 모든 information이다.
좀 더 구체적으로 표현하면 시간 t에서 value 또는 entity 집합으로의 mapping(함수)이다.
Resource는 그 의미(semantic)에 의해 구별 가능하다. 즉, information의 의미가 곧 resource이다.
representation은 특정 시점에 요청받은 resource의 값(모습)이다.
- static resource : 요청을 보내는 시간에 관계 없이 semantic만으로 대응되는 값이 결정된다.
- non-static resource : 요청을 보내는 시간에 대해 대응되는 값이 변한다.
[resource01] 현재 서울 날씨
[resource02] 22.01.18 서울 날씨
위의 두 resource는 요청 시간에 따라 같은 값을 가질 수 있지만 서로 다른 resource이다. 그 의미가 다르기 때문이다.
이런 resource에 대한 추상적인 정의는 Web architecture의 핵심 기능들을 가능하게 만든다.
- 다양한 정보의 원천(source)들을 타입이나 구현체를 신경 쓰지 않고 포함(encompass)하여 Generality(보편성) 획득
- late binding(참조를 representation에 연결함)을 가능하게 한다
- reference는 구체적인 데이터가 아닌 추상적인 개념을 가리키기 때문에 representation이 바뀌더라도 링크를 수정할 필요가 없게 된다
REST는 resource identifier를 사용하여 component들의 interaction(통신)이 어떤 resource에 대한 것인지 식별한다.
REST connector는 일반적인(generic) 인터페이스를 제공한다. 이 인터페이스들을 사용해 resource의 value set에 접근하고 값을 조작할 수 있다. 이 때 이런 요청을 처리하는 프로그램의 구현은 전혀 신경 쓸 필요가 없다.
generic interface의 예로는 HTTP method가 있다.
Resource identifier를 정한 naming authority는 해당 resource의 의미에 맞는 representation이 대응되도록 유지해야 한다.
5.2.1.2 Representation
Representation은 일련의 byte들이다. Representation metadata는 그 byte들을 설명한다.
Representation 다른 이름은 document, file, HTTP message entity 등이다.
Representation은 data, metadata, 무결성 체크를 위한 metadata로 구성된다.
metadata는 key-value pair 형태이고 name은 value의 구조와 의미를 정의하는 기준이 된다.
Control data는 component가 주고받는 message의 목적을 정의한다. 목적이란 요청된 action 또는 response의 의미이다.
또한 control data는 request를 매개변수화(parameterize)하고 connecting element의 기본 행동(default behavior)을 바꿀 수 있다. 예를 들면 요청 또는 응답 message에 포함된 control data를 통해 cache behavior를 바꿀 수 있다.
Message control data에 따라 주어진 representation은 요청된 현재, 원하는 상태의 resource 또는 error를 가리킬 수 있다. 예를 들어 resource에 대한 원격 authoring은 server로 representation을 보내는 과정을 필요로 하는데, 이 과정을 통해 해당 resource에 대한 value를 만들 수 있다. 이 value는 이후에 request에 의해 조회될 수 있다.
Media type이란 representation의 data format이다. Representation은 message에 포함되어 recipient에게 전달되고 recipient는 control data와 media type의 종류를 보고 message를 처리한다.
Media type은 사용자가 체감하는 분산 하이퍼미디어 시스템 성능에 직접적인 영향을 미친다.
Rendering 시작 전에 모든 data를 전송받아야 하는 media type의 data는 component간의 interfaction에 지연을 추가한다.
반면 중요한 렌더링 정보가 앞부분(메모리 주소값이 작은 부분)에 위치하여 정보가 전달되는 동안에도 렌더링이 가능한 data format은 전자보다 사용자가 체감하는 성능이 훨씬 뛰어나다(네트워크 성능이 동일한 경우더라도).
representation
message = control data + representation
- control data : message의 목적(요청하는 action, response의 의미) 정의, request를 매개변수화(parameterize)
- representation = data + metadata + integrity check(optional)
- data : byte 배열
- metadata :
key-value형태. ex) Media type
Comments