한빛출판네트워크

제공 : 한빛 네트워크
저자 : Mike Amundsen
역자 : 정준영
원문 : A Matter of Semantics

하이퍼미디어 메시지(Hypermedia messages)를 이용하여 client-server 통신 구성하기

웹(Web) 상의 메시지는 3가지 정보를 나르고 있다. 구조적 의미(Structure Semantics), 통신규약상의 의미(Protocol Semantics), 응용상의 의미(Application Semantics). 구현 방식이 어떻든 간에 이 세 가지 정보는 클라이언트-서버 간의 성공적인 통신을 위해서는 반드시 필요하다. 이 삼인조(S-P-A)형태는 분산 네트워크 통신에서 핵심이다.

하지만, 평소 구현을 할 때 이런 구분은 애매하고 뒤섞여있다. 예를 들어, "당신은 이 URL로 새로운 사용자를 추가할 수 있습니다" 라고 말하는 것처럼 많은 경우에서 통신규약상의 의미(어떻게 유효한 네트워크 접속을 만들 것인가)와 응용상의 의미 (사용자, 고객, 주문 같은 도메인 이름)를 뒤섞여 사용하고, 둘 다 사람이 읽을 수 있는 문서나 클라이언트를 구현한 소스코드 안에만 정의되어 있을 뿐이다. 달리 말하면 프로토콜 수준과 애플리케이션 수준의 의미가 밀접하게 연결되어 있다. 이것을 확인할 쉬운 방법은 당신이 동일한 메시지 포맷으로 HTTP가 아닌 다른 프로토콜(예를 들어 웹소켓(WebSockets) 이나 FTP)로 API를 구성할 수 있는지 여부를 보면 된다. 나는 2010년에 이것을 프로토콜 회의론적 디자인 패턴이라고 설명하였다("A RESTful Hypermedia API in Three Easy Steps").

하지만, 이들을 분리한 채 유지하고, 그 각각을 살펴볼 수 있는 방법이 있다. 그렇게 함으로써 융통성을 높이면서 메시지의 품질과 가치를 강화할 수 있다.

구조적 의미

구조적 의미는 어떻게 적격한 메시지를 만들 것인가를 고려할 규칙을 제공한다. XML은 다소 간단한 구조적 의미(structure semantics) 를 가지고 있다. JSON의 적격성 판단은 더 모호하지만 JSON.parse() 가 적격성을 판단할 수 있음이 밝혀졌기 때문에 구현 가능한 것으로 보인다. 보다 복잡한 형태(HTML, Atom, HAL, Collection+JSON)에 대해 적격성을 판단하는 것은 유효성 검사 도구가 항상 있는 것이 아니라서 훨씬 어렵지만 불가능한 것은 아니다.

구조적 의미를 가지지 않는 웹서비스를 구현하는 것은 어렵지만, 할 수 있다면 좋은 것이다.

통신규약상의 의미

통신규약상의 의미(Protocol Semantics)는 하나 이상의 메시지 통신 규약을 사용하는 유효한 요청과 결과를 만드는 방법에 대한 것이다. HTTP, FTP, WebSockets 등은 모두 메시지 통신 규약이다. 웹에서 대부분의 구현은 이러한 의미를 설명하기 위하여 사람이 읽을 수 있는 문서화를 사용한다. 예를 들어, 전형적인 RPC 스타일의 구현은 URI와 관련된 요청 규칙(HTTP 메서드와 헤더)과 가능한 콘텐츠를 문서화 한다.

하이퍼미디어 스타일의 구현은 메시지에 통신규약상의 의미를 표시한다(보통은 body 부분에 나타나지만 때때로 HTTP 헤더에 나타나기도 한다). 이런 것들이 이루어지는 가장 일반적인 방법은 서버의 응답에 있는 링크와 양식을 위한 규칙을 포함하는 것이다.

기존에 등록된 미디어 타입은 종종 하이퍼미디어(Hypermedia)에 대한 제어를 포함하지 않을 수 있다. 예를 들어, CSV와 XML, JSON 은 메시지 내용에 하이퍼미디어를 위한 정의를 가지고 있지 않다. 하지만, HTML이나 Atom, HAL, Collection+JSON 또는 다른 어떤 것은 미리 정의된 프로토콜 수준의 정보를 서버가 보낸 메시지에 포함하고 있다.

응용상의 의미

응용상의 의미는 응용에 특화된 정보를 클라이언트와 서버가 공유하는 방법을 통제한다. 이것은 해당 도메인의 데이터 요소(사용자, 고객, 상품 등)의 이름과 도메인 내에서의 행동(사용자를 추가하거나, 구매에 대한 세금을 계산하는 등)을 포함한다. 적격한 요청과 응답은 각각 도메인에 특화된 개념에 대한 유효한 표현을 가지고 있다. 이 정도 수준의 특수함을 가진 미디어 타입 설계는 거의 없으나 일부 존재하는 것은 업계 전반의 도메인을 목표로 하는 것이다.(예를 들어 VoiceXML과 Maze+XML).

기존 존재하는 구조적 양식(XML, JSON 등)과 결합가능하고 기계가 판독 가능한 응용의 예가 있다. XSD, JSON-Schema 같은 schema 기반의 문서 타입은 응용에 특화된 정보를 표현하기에 아주 적합하다. SOAP를 위한 WSDL이나 그의 사촌격인 WADL도 또 다른 예이다..

대부분의 응용 수준의 의미는 정보를 메시지에 적용할 표준화된 방법 없이 독자적인 형태로 존재한다. 일부 미디어 타입은 다른 것에 비해 응용 수준의 의미를 지원하기에 더욱 좋다. 예를 들어, HTML은 (id, name, class, rel) 같은 속성을 가지고 있는데, 이것을 이용하여 메시지에 응용 수준의 의미를 적용할 수 있다.

시멘틱 프로파일

응용상 의미의 다른 접근 방식은 프로파일을 이용하는 것이다. Tantek Celik이 2003년에 XHTML 메타데이터 프로파일(XHTML Meta Data Profiles)을 발표한 이후 이러한 방식을 옹호하고 있다. 프로파일 연결 관계(profile link relation)는 최근에 IANA에 등록되었고 이러한 방식에 대하여 새로운 관심이 생기고 있다. POWDER 규격은 "describedby" 라는 비슷한 연결 관계를 사용하고 있다.

프로파일 패턴은 프로토콜이나 구조와 독립된 응용상 의미의 개요를 설명하도록 한다. 모든 데이터(사용자 이름, 주소, 이메일, 전화번호 등)와 가능한 행동(사용자 추가, 사용자 수정, 사용자 승인 등)을 한곳에 모을 수 있다. 프로파일은 프로토콜(HTTP, WS 등) 이나 포맷(XML, Atom, HTML 등)이 섞이지 않도록 하면서도 항상 최신 상태를 유지할 수 있도록 문제에 대한 명확하고 독립적인 설명을 제공한다.

더 놀라운 건, 기계가 처리할 수 있는 프로파일을 만들 수 있어서, 클라이언트와 서버가 실행 중에 참고할 수 있다는 것이다. Application-Level Semantic Profile(ALPS) 포맷은 이러한 목적으로 설계되었다. 이것은 다양한 미디어 타입(구조)와 프로토콜에 적용될 수 있는 프로파일 사양을 만들기 위한 초기 시도이다.

설계 특징

메시지 포맷을 설계하는 것은 세가지(structure, protocol, application)에 대한 해결책을 찾는 것이다. 가장 단순한 접근 방법은 기존에 존재하는 구조화된 포맷(XML, JSON 등) 중에서 고르고, 나머지 두 가지(protocol, application)에 사람이 볼 수 있는 문서화를 사용하는 것이다. 이 방식은 클라이언트와 서버 구현간에 협동이 필요하지만 가장 일반적인 방법이다.

통신규약상의 의미와 응용상의 의미를 메시지에 포함하는 미디어 타입을 고르거나 설계하는 것은 메시지 설계자에게 더 많은 책임을 주고 클라이언트와 서버 간 상호작용하는 방식을 표준화한다. 이것은 호환성 있는 구현이 시간상 또는 공간상 멀리 떨어져서 이루어질 수 있고 클라이언트 또는 서버 개발자들이 초기 메시지 설계자와 협업이 없어도 새로운 상호 작용을 추가는 것을 포함하여 안전하게 통신을 발전시킬 수 있는 기회를 가질 수 있는 가능성을 증가시킬 수 있다.

시간/거리에 대한 지원과 진화가능성이라는 웹의 두 가지 특징은 하이퍼미디어 스타일 설계의 전형적인 특징이다.