REST

REST

위키백과, 우리 모두의 백과사전.

이동: 둘러보기, 찾기

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 그는 하이퍼텍스트 전송 프로토콜(HTTP)의 주요 저자들 가운데 한 사람이다. 그 뒤로 이 개념은 네트워킹 문화에 널리 퍼졌다.

엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법에 대한 개괄을 말한다. 간단한 의미로는, 도메인 지향 데이터를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 당연히 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP 프로토콜을 사용하지 않은 채로 또 월드 와이드 웹에서 전송하지 않고도 아주 커다란 소프트웨어 시스템을 설계하는것도 가능하다. 또한, 리모트 프로시저 콜을 이용하는 대신에 간단한 XML과 HTTP 인터페이스(REST 원리에 부합하지는 않지만)를 이용해 설계하는 것도 가능하다. 현실 세계에서의 REST 용어에 대한 이러한 두 가지 의미는 기술 토론에서 종종 혼란을 야기한다.

필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

원리

REST의 지지자들은 웹이 몇 가지 핵심 설계 원칙의 직접적인 결과로서 확장성과 성장성을 갖게 되었다고 주장한다.

• 응용 프로그램의 상태와 기능들은 리소스들로 나뉜다.
• 모든 리소스는 하이퍼미디어 링크를 사용하는 공통 문법을 이용하여 유일한 방식으로 주소를 지정한다.
• 모든 리소스들은 클라이언트와 리소스 사이의 상태 전송을 위한 유일한 인터페이스를 공유한다. 다음과 같이 이루어져 있다.
  • 잘 정의된(well-defined) 명령어들의 제약 집합.
  • 콘텐츠 종류와, Code on demand를 부분적으로 지원하는 제약 집합

• REST 아키텍처에 적용된 6가지 제한 조건 (개별 컴포넌트의 구현은 자유롭게 디자인할 수 있다)
  • 클라이언트/서버 구조 - 유니폼한 인터페이스로서 분리되어야 한다
  • 무상태(Stateless) - 각 요청 간 클라이언트의 컨텍스트가 서버에 저장되어서는 안된다
  • 캐시 처리 가능(Cacheable) - WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
    • 잘 관리되는 캐싱은 클라이언트-서버 간 interaction을 부분적으로 또는 완전하게 제거하여 scalability와 performance를 향상시킨다.
  • 계층화(Layered System) - 클라이언트는 보통 대상 서버에 직접 붙었는지, 또는 중간의 intermediary 서버와 붙었는지를 알 수 없다. Intermediary 서버는 로드 밸런싱을 가능하게 하거나 공유 캐시를 제공함으로써 시스템 scalability를 향상시키는 데 유용하다.
  • Code on demand (optional) - 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
  • Uniform Interface - 아키텍처를 단순화시키고 decouple시켜서 클라이언트, 서버 각 파트가 독립적으로 개선될 수 있도록 해준다.

• REST 인터페이스의 원칙에 대한 가이드
  • 리소스의 구별
    • 개별적인 리소스는 요청에서 구별된다 - 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 리소스 그 자체는 클라이언트로 리턴되는 representation으로부터 개념적으로 분리되어 있다. 예를 들어, 서버는 그 데이터베이스를 전송하지 않는다, 단지 아마 어떤 데이터베이스 레코드를 나타내는 HTML, XML이나 JSON 등이 요청에서 구체적으로 요구되거나 서버의 구현에 따라서 예를 들어, 프랑스 어로, UTF-8로 인코딩되어 보내질 것이다.
  • 이들 representation을 통한 리소스의 조작
    • 클라이언트가 어떤 메타데이터가 첨부된 상태로 어떤 리소스의 representation을 가지고 있을 때, 만약 승인이 있다면, 서버에 있는 그 리소스를 변경 또는 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
  • 자기-서술적 메시지
    • 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다 - 예를 들어 어떤 파서를 불러야 하는지. 그 한 예는 MIME type과 같은 인터넷 미디어 타입의 사용을 들 수 있다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기-서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 코드 다운로드가 사용되지 않으면, 그 내용을 가지고 무엇을 해야할지에 대해 충분히 알려주지 못한다.
  • 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어
    • 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 representation에서 구별될 수 있어야 한다. 충분한 컨텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

• REST 의 주요한 목표
  • 컴포넌트의 상호 연동 상의 확장성(scalability of component interactions)
  • 인터페이스의 범용성(Genrality of interfaces)
  • 컴포넌트의 독립적인 배포(Independent deployment of components)
  • 지연을 감소시키고, 보안을 강화하고, 레거시 시스템을 인캡슐레이션 시키는 중간 컴포넌트(Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

같이 보기

• 원격 프로시저 호출
• XML-RPC/JSON-RPC
• SOAP
• HTTP

바깥 고리

• Principled Design of the Modern Web Architecture (PDF) 115–150. Association for Computing Machinery (2002년 5월).

• Fielding, Roy Thomas (2000). Architectural Styles and the Design of Network-based Software Architectures (HTML). University of California, Irvine.

• RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision (HTML) (2008년 4월).

 

출처 : http://ko.wikipedia.org/wiki/REST