REST의 Resource, Representation 이해하기
REST 에 대해 잘 이해하기 위해서는 Resource (자원), Representation (표현) 에 대해 잘 이해하고 있어야 하는 것 같습니다. 이 글에서는 REST 의 Resource 와 Representation 에 대해 정리해 봤습니다.
Resource
REST 에서 리소스는 ‘이름을 붙일 수 있는 모든 정보’라고 합니다. 리소스는 문서나 이미지가 될 수도 있고 날씨 정보, 현실 세계의 어떤 객체 등 모든 것이 리소스가 될 수 있습니다.
로이 필딩의 REST 논문에서는 리소스를 정보의 핵심 추상화 (Key abstraction of information) 라고 표현하고 있습니다. 개념 자체가 추상화된 것이기 때문에 쉽게 이해하려면 구체적인 예시가 있어야 될 것 같습니다.
REST 에서는 ‘하이퍼텍스트 참조 대상이 될 수 있는 모든 개념은 리소스의 정의에 부합해야 한다’고 합니다. 말이 조금 어려운데요. HTTP 1.1 명세에서는 리소스가 요청의 대상 이고 URI 로 식별이 가능해야 한다고 합니다. REST 와 HTTP 문서를 함께 보면 이해하기 조금 더 수월한 것 같습니다.
또한 ‘리소스는 특정 시점의 엔티티 집합의 개념적인 매핑’이라고 합니다. ‘인사말’ 에 대한 예제를 살펴보면 좋을 것 같습니다.
대한민국
- 안녕하세요?’
일본
- 아침: 오하요-고자이마스
- 점심: 곤니찌와
- 저녁: 곤방와
우리나라에서는 언제 만나든지 안녕하세요가 보통의 인사말입니다. 하지만 옆 나라 일본에서는 아침, 점심, 저녁 시간에 따라 인사말이 달라지죠. 아침에는 ‘오하요ー고자이마스’, 점심에는 ‘곤니찌와’, 저녁에는 ‘곤방와’ 라고 한다고 합니다.
여기서 리소스는 무엇이 될까요? ‘안녕하세요’, ‘오하요-고자이마스’, ‘곤니찌와’, ‘곤방와’ 각각이 리소스가 될까요? REST 의 개념에 따르면 인사말 각각이 리소스가 되는 것이 아니라 ‘인사말’ 이라고 하는 개념이 리소스가 됩니다.
이런 리소스의 추상적인 정의는 아래와 같은 이유로 웹 아키텍처의 주요 기능(Client-Server, Uniform-interface, HATEOAS 등)을 가능하게 한다고 합니다.
- 정보의 유형이나 구현에 따라 인위적으로 구분하지 않고 많은 정보를 포괄해서 일반성을 제공한다.
- Representation 에 대한 참조를 나중에 바인딩 할 수 있기 때문에 요청의 특성에 따라 Content-Negotiation 을 할 수 있다.
- 단일 표현이 아니라 개념을 참조할 수 있기 때문에 Representation 이 변경되어도 기존의 링크를 변경하지 않아도 된다.
Representation
REST 에서 Representation(표현)은 리소스의 현재 또는 의도된 상태를 담아내기 위한 정보입니다. REST 의 컴포넌트(Client, Server, Cache 등)들은 리소스를 담고 있는 표현을 주고 받는 것 입니다.
우리가 주로 사용했던 Http Request, Response (document, file 등)이 표현이 될 수 있습니다. 로이 필딩은 이것들이 자주 사용되는 ‘표현’이지만 덜 정확한 이름이라고 합니다.
표현은 표현 데이터, 표현 데이터를 설명하는 메타 데이터로 구성되어 있습니다. 경우에 따라서는 메타 데이터의 메타 데이터도 포함될 수 있습니다.
쉬운 이해를 위해 간단한 예시를 들어보겠습니다. 위에서 나온 ‘인사말’ 에 대한 표현입니다.
- 한글 인사말에 대한 HTTP 메세지 (Response)
Content-Type: text/plain
Content-Language: ko
Date: Mon, 14 Aug 2023 07:04:28 GMT
Server: Greeting
안녕하세요
- 일본어 인사말에 대한 HTTP 메세지 (Response)
Content-Type: text/html; charset=UTF-8
Content-Language: ja
Date: Mon, 14 Aug 2023 07:04:28 GMT
Server: Greeting
<html>
<head>
...
</head>
<body>
<div>
おはよう
</div>
</body>
</html>
여기서 표현 데이터는 안녕하세요, <html>..おはよう..</html> 이고, 메타 데이터는 Response 헤더의 Content-Type, Content-Language 가 될 수 있겠습니다. 헤더 전체가 표현의 메타 데이터는 아닙니다. 아래 4개의 헤더가 표현의 메타 데이터입니다.
- Content-Type
- Content-Encoding
- Content-Language
- Content-Location
표현의 응답 메세지 (Response) 에는 현재 표현에 특정되지 않은 메타 데이터가 포함될 수 있습니다. 응답 메세지에 포함된 제어 데이터는 컴포넌트 간의 메세지 목적을 정의한다고 합니다. 예를 들어 응답 메세지에 포함된 제어 데이터로 캐시 동작이 변경될 수 있습니다.
표현의 데이터 형식을 미디어 유형이라고 합니다. Content-Type 헤더 안에 Media type 을 표현할 수 있습니다. 수신자는 미디어 타입을 보고 사용자가 볼 수 있도록 렌더링 하는 등의 처리를 할 수 있습니다.
표현이라고 된 예시를 살펴보면 우리가 그동안 익숙하게 봤던 HTTP 메세지인 Request, Response 는 모두 표현(Representation)이었습니다. 어떤 URI 로 리소스를 요청하면 우리가 받았던 것은 리소스 자체가 아니라 표현이었던 것 입니다.
이렇게 리소스와 표현이 분리되어 있어서 같은 리소스라고 해도 다양한 표현이 만들어질 수 있습니다. 위에서 간단한 예제로 살펴봤던 표현들은 모두 같은 URI 로 요청된 응답입니다. Accept 헤더를 보고 서버가 적절히 데이터를 선택(Proactive Content-Negotiation)해서 응답하기 때문에 하나의 URI 로 ‘인사말’ 이라는 자원을 요청하고 각각 다른 표현을 받을 수 있습니다. 추가로 ‘안녕하세요’에서 ‘안녕하세요^^!’ 라고 데이터가 변경되어도 URI 는 변경되지 않습니다. 리소스와 표현이 분리되어 있다는 것이 유연성을 제공해줍니다.
REST 에 대해 잘 알고 있다고 생각했는데 이렇게 글로 정리하고 또 여러가지 정보를 찾아보니 정확하게 알고 있는 것이 아니었구나 하는 것을 깨닫게 된 것 같습니다. 다음에는 REST 의 Uniform Interface 에 정리해보려고 합니다.