이런 저런 얘기를 나누던 차에 사용하는 프레임워크가 Jersey란다.
Jersey 써 본 적 있으세요? 라는 질문에 ありません。이라고 대답할 수 밖에 없었다.
그럼 Jersey Framework는 뭐지? 라는 의문이 들어 정리해 보기로 했다.
Jersey Framework
Jersey RESTful Web Services framework is an open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation.
The following components are part of Jersey:
- Core Server: For building RESTful services based on annotation (jersey-core, jersey-server, jsr311-api)
- Core Client: Aids you in communicating with REST services (jersey-client)
- JAXB support
- JSON support
- Integration module for Spring and Guice
우선 두 단어가 많이 보인다.
RESTful 그리고 JAX-RS이다.
RESTful이란?
REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 그는 하이퍼텍스트 전송 프로토콜(HTTP)의 주요 저자들 가운데 한 사람이다. 그 뒤로 이 개념은 네트워킹 문화에 널리 퍼졌다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법에 대한 개괄을 말한다. 간단한 의미로는, 도메인 지향 데이터를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 당연히 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP 프로토콜을 사용하지 않은 채로 또 월드 와이드 웹에서 전송하지 않고도 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜을 이용하는 대신에 간단한 XML과 HTTP 인터페이스(REST 원리에 부합하지는 않지만)를 이용해 설계하는 것도 가능하다. 현실 세계에서의 REST 용어에 대한 이러한 두 가지 의미는 기술 토론에서 종종 혼란을 야기한다.
필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.
원리
REST의 지지자들은 웹이 REST의 핵심 설계 원칙을 통해 확장성과 성장성을 갖게 되었다고 주장한다.
- 응용 프로그램의 상태와 기능은 리소스들로 나뉜다.
- 모든 리소스는 하이퍼미디어 링크를 사용하는 공통 문법을 이용하여 유일한 방식으로 주소를 지정한다.
- 모든 리소스들은 클라이언트와 리소스 사이의 상태 전송을 위한 유일한 인터페이스를 공유한다. 다음과 같이 이루어져 있다.
- 잘 정의된 명령어들의 제약 집합.
- 콘텐츠 종류와, Client-side_scripting|Code on demand를 부분적으로 지원하는 제약 집합
- REST 아키텍처에 적용된 6가지 제한 조건 [1]
- 클라이언트/서버 구조 - 일관적인 인터페이스로 분리되어야 한다
- 무상태(Stateless) - 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
- 캐시 처리 가능(Cacheable) - WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
- 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
- 계층화(Layered System) - 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 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)
JAX-RS란?
SOAP기반의 SOA 연동은 자바 애플리케이션을 무겁게 한다는 비판과 함께, 최근 웹 애플리케이션의 경향인 AJAX기반으로 JSON이나RSS와 같이 간결한 프로토콜을 사용한 연동이 보편화되면서 쉽게 구현할 수 있도록 Java EE에 JAX-RS 라는 사양이 포함되고 있다.
출처 : http://en.wikipedia.org/wiki/Project_Jersey#cite_note-1http://ko.wikipedia.org/wiki/REST
http://ko.wikipedia.org/wiki/JAX-RS
Jersey Framework에 대해 좀 더 알게되면 더 추가하도록 하겠다.
