REST(Representational State Transfer), RESTful 개념

일반적인 개념?

XML, HTTP를 사용하는 웹 기반 인터페이스

원래 개념?

웹과 같은 네트워크 시스템을 위한 원칙

REST의 주요 원칙? 지켜야 하는것?

클라이언트 서버(웹으로 보면 브라우저 / 웹서버) : Stateless (Session, Cookie 사용하지 않는것, 따라서 매번 인증키를 넘겨야 한다)

보편적인 인터페이스 (HTTP Method로 정의 된다. GET/POST/DELETE/PUT... )

자원은 URI를 통해 유일하게 지정된다.

각 자원들은 URI를 통해 서로 연결될 수 있다

RESTful?

REST의 원칙을 잘 지켜 웹통신을 하는가 물어보는것

RESTful한 원칙을 잘 지켰는지 알아보는 방법?

1. API의Endpoint가 오직 한개인가?

하나의 URL에 모든 정보를 던져주고 있지 않은가? 

REST는 모든 Resource(예를 들어서 “영화 예매 시스템“일 경우 “고객“, “예약번호“, “좌석번호“, “영화정보” 같은 것) 리소스를 유일한 URL 값으로  매핑한다. 만약 하나의 URL에 여러개의 파라미터 정보등을 "XML 형태의 Body 데이터"로 던지고 있다면 이것은 RESTful 하지 않은 것이다. 왜냐하면 다른 리소스를 요청하는 경우에도 URL이 같기 때문에 리소스마다 Unique한 URL을 가지고 있지 않기 때문이다.

2. 모든 요청을 POST 방식으로만 요청 하는가?

"RESTful"한 설계에서 자원의 생성은 “POST“, 수정은 “PUT“, 조회는 “GET“, 삭제는 “DELETE” 메서드를 사용한다.

예를 들면

예약 생성 : POST /reservation/2013012500001

예약 수정 : PUT /reservation/2013012500001

예약 조회 : GET /reservation/2013012500001

예약취소 : DELETE /reservation/2013012500001

다음과 같이 된다.

실제 실무에서 이런 부분에 대해서 오해하게 된다면 아래와 같은 방식으로 표현하게 된다.

예약 생성 : POST /reservation/2013012500001?cmd=insert

예약 수정 : POST /reservation/2013012500001?cmd=update

예약 조회 : POST /reservation/2013012500001?cmd=select

예약취소 : POST /reservation/2013012500001?cmd=delete

이와 같은 표현은 “RESTful“한 설계라고 할수 없다.

3. 응답에 대한 메타데이터를 Body에 포함 하는가?

"RESTful"한 설계에서는, 응답 상태 결과값을 body에 저장하지 않고 HTTP 프로토콜 방식을 준수해야 한다.

예를 들어 클라이언트에서 요청 후 “처리 결과 값이 성공“일 경우 해당 시스템은 처리 결과를 “Body”에 포함하는 것이 아니고, HTTP Status의 값으로써 표현한다.

 그런데 만약 추가되는 부분이 있다면 얘는 어쩔 것인가? 이 경우 별도로 사용자 정의 코드를 만들어 관리하면 된다. HTTP 헤더에 스펙에 정의된 내용만 존재하는 것이 아니다. 충분히 사용자 정의해서 헤더 내용을 추가 시키는 경우가 가능하다.

"RESTful"한 요청 예를 들어 보자.

사용자 정보가 없을 경우는 : 404 (Not Found)

요청 정보가 정확하지 않을 경우 : 400 (Bad Request)

인증 실패 : 401 (UNAUTHORIZED)

즉, 이러한 전송에 대한 메타 데이터(결과 값, 세션 키)는 최대한 HTTP 헤더로 선언하고 실제 "Body 데이터"는 위에서 언급한 "Resource의 순수한 데이터"만을 전송 해야 한다.

4. URL에 동사(Verb)가 포함 되어 있는가?

위에서 언급했듯이 "RESTful"한 API 설계에서 시스템에서 제공하는 것들은 "Resource"라고 말하고,"URL"로 표기 한다고 되어 있다. 또한 이러한 "Resource"들은 "명사(noun)"적 특성이 강하다.

따라서 만약 "URL"로 표기할때 동사(Verb)가 포함이 되면 혼돈이 올수 있다. 행위적 표현이기때문에 RPC(메서드)를 의미하는지 "Resource"를 하는지 구분이 모호해 질 수 있기 때문이다.

예를 들어서 예약 상태 정보를 조회를 하기 위해서 “/reservation/001/activate“

라는 표현 보다 “/reservation/001/status” 라고 표현 하는 것이 낫다.

5. URL에 RPC 호출 메서드 명이 있는가?

다양한 시스템 연동 스펙을 보면 아래 와 같이 실제 존재하는 비지니스 컴포넌트(자바 클래스) 메서드를 URL에 포함해서 호출하는 경우가 있다.

?action=createReservation

?action=modifyReservation

?action=findReservation

?action=removeReservation

또한 URL에 노출되지는 않지만 “Body“안에 “XML” 형태로 선언 하는 경우도 있다.

하지만 "RESTful" 설계 목적은 "RPC (Remote Procedure Call)"에 있는 것이 아니고 시스템에서 제공하는 "Resource"를 "bucket"화 하는 것이다.

그럼 "RESTful" 아키텍쳐는 어디다 쓰는게 좋을까?

"RESTful" 아키텍쳐는 외부환경과 일관된 기준으로 통신을 하기 때문에, “외부 OpenAPI“에 매우 적합한 연동 아키텍쳐가 될수 있다.

REST가 과연 무엇인가..

 

REST 웹서비스의 발표를 준비하면서 여기저기서 주어온 정보들을 종합해본다.

 

내용은 발표형식이니 이해바랍니다.

 

그럼 시작합니다.

 

1. REST의 탄생배경으로는 다음과 같습니다.

기존 웹서비스 전달 프로토콜인 SOAP(simple Object Access Protocol)은 HTTP응용 프로토콜로서SOAP 헤더와 바디로 구성되어 있고, 메시지 송수신 시 헤더와 바디의 인코딩/디코딩 과정이 필수입니다. 따라서 기본 HTTP로 메시지를 전달하던 인터넷 서비스 분야에서는 원하는 기능에 비해 SOAP 프로토콜 처리의 오버헤드가 발생하는 문제가 있습니다.

 

(여기서 오버헤드란, 시스템에서 목적으로 하는 효과를 얻기 위해 본질적인 것은 아니지만 요구되는 작동, 또는 그 때문에 필요한 자원을 말합니다.) 

 

이런 SOAP의 단점을 보완하고자 등장한 구현 기술이 바로 RESTful 웹서비스입니다. RESTful 웹서비스는 REST 기반의 웹서비스를 의미하고, HTTP의 기본 기능만으로 원격 정보에 접근하는 웹 응용 기술입니다. 

 

RESTsms 웹의 창시자 중 한 사람인 Roy Fielding이 그의 박사 학위 논문에서, 현재의 웹 아키텍처가 웹의 본래 설계의 우수성을 활용하지 못하므로 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 제안했는데 이것이 REST입니다.

 

REST는 REpresentational State Transfer의 약어로서 부수적인 레이어나 세션 관리를 추가하지 않고도 HTTP프로토콜로 데이터를 전달하는 프레임워크입니다. 또한 클라이언트/서버 간의 구성요소를 엄격히 분리하여 구현은 단순화시키고 확장성과 성능은 높일 수 있는 아키텍처입니다.

 

2. REST를 알려면 SOAP와 비교를 하는 것이 가장 쉬운데요.

 

그럼 SOAP와 REST를 비교해 보겠습니다.  

 

 

첫째로 서비스구조를 비교해보겠습니다. 

 

 

 

보시는 바와 같이 SOAP는 SOA(Service Oriented Architecture)로 서비스 지향 구조에 근거합니다. 이는 서비스 제공자가 UDDI에 레지스트리를 등록하고, 서비스 요청자가 원하는 서비스를 UDDI에서 검색한 후에 서비스를 요청하면 제공자는 그에 응답을 해줍니다. 반면 REST는 ROA(Resource Oriented Architecture) 즉, 리소스 지향 구조를 근거로 합니다. 이는 요청자가 리소스로 요청하면 중간 매체 없이 제공자가 직접 리소스로 응답을 해줍니다. 여기서 리소스(resource)란 REST 아키텍처의 핵심 요소로서 웹사이트, 블로그, 이미지, 음악, 이용자, 지도, 검색결과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미합니다. REST 구조에서의 리소스는 그들의 고유한 URI를 가집니다.

 

서비스 실행 관점에서 살펴본다면, SOAP 기반 웹서비스에서는 서비스 제공자와 요청자 간에 SOAP 프로토콜로 메시지를 주고 받는 방식으로 서비스를 이용합니다. 즉, 서비스 요청자가 웹서비스 요청을SOAP으로 인코딩하여 서비스 제공자에게 전달하면, 서비스 제공자는 이를 디코딩하여 적절한 서비스 로직을 통하여 결과를 얻고, 그 결과를 다시 SOAP 인코딩하여 서비스 요청자에게 반환합니다. 이러한 인코딩/디코딩의 과정에서 오버헤드가 생기게 됩니다. 한편, RESTful 웹서비스는 특정 uri로 리소스를 요청하면 기본 HTTP 프로토콜의 메소드 GET/PUT/POST/DELETE를 이용하여 JSON, XML, RSS 등 다양한 형태로 표현된 리소스를 직접 실어 나릅니다.

 

서비스 기술적인 요소는 다음 그림으로 확인하겠습니다. 

 

 

SMTP [ simple mail transfer protocol ] 인터넷 상에서 전자 메일을 전송할 때 쓰이는 표준적인 프로토콜.

WSDL [web Services Description Language] 비즈니스 서비스를 기술하여 비즈니스들끼리 전자적으로 서로 접근하는 방법을 제공하기 위해 사용되는 xml기반의 언어.

WADL [Web Application Description Language] HTTP 기반 웹 응용 프로그램에 대 한 컴퓨터 판독이 가능한 XML 기반의 파일 형식입니다

아래 그림은 고객의 주문을 관리하는 기능을 가지는 웹서비스를 soap와 rest기반이 어떻게 다른지 보여줍니다.

 

SOAP 기반의 웹서비스에서는 고객의 정보, 주문정보 등을 검색, 변경, 삭제하는 오퍼레이션이 각기 존재하여 필요한 기능을 수행할 때 해당 오퍼레이션을 호출하는 방식으로 일반적인 프로그래밍 개념과 동일합니다.

반면에 RESTful 웹서비스(b)에서는 총주문(/order), id를 가지는 특정 주문(/order/{id}), 총고객(/customers), 고객 한 명을(/customer/{id}) 모두 리소스로 정의하고, 각 리소스에 URI을 할당한 후 URI에 대해 HTTP GET/ PUT/POST/DELETE 오퍼레이션을 수행합니다. 

 

 

예를 들어, ‘주문번호 25의 주문 상세 내역을 가져와라’라는 요청은 SOAP 기반

웹서비스라면 getOrderDetails(order_no=25)로 호출될 것이며, RESTful 웹서비스라면 http GET/order/25로 수행할 것이다. 즉 order 25가 리소스로서 GET 메소드로 관련 정보를 얻을 수 있습니다.

이와 같이 SOAP 기반의 웹서비스를 사용하고자 할 때에는 웹서비스의 위치(바인딩 주소)뿐 아니라 오퍼레이션을 알아야 하는 반면, RESTful 웹서비스를 사용하고자 할 때에는 대상 리소스의 URI만 파악하면 됩니다. 이것은 모든 RESTful 웹서비스가 HTTP메소드라는 공통의 인터페이스를 이용하므로 가능한 일이라 하겠습니다. 

3. 그렇다면 REST는 어떠한 특징을 가지고 있는지 살펴보겠습니다.

REST는 다음 4가지를 꼭 필요로 하기 때문에 별칭으로 need 4 speed라고 붙여보았습니다. 

 

(아는이만 안다. 니드포스피드가 뭔지.. 님하는 아는이?) 

첫째로 Addressable Resource : Every "thing" should have a URI

-모든 것은 URI를 가지고 있어야 합니다. 즉, 모든 Resource는 클라이언트가 바로 접근 할 수 있는URI를 가지고 있습니다.

둘째로 Statelessness : scalability and decoupling 확장성과 비동기화입니다.

-웹 어플리케이션이 클라이언트의 상태에 대한 정보를 보관하지 않습니다. 모든 HTTP요청이 완전히 독립적으로 발생합니다. 이는 클라이언트가 매 요청을 할 때마다 필요한 모든 정보를 줍니다.

셋째로 Representation Oriented : Different applications need different formats

-서버는 클라이언트의 time out에 대해 신경 쓸 필요도 없고, 클라이언트가 애플리케이션의 "어디"에 있었는지 기억한 정보를 잃어버릴 일도 없습니다. 클라이언트는 매 요청마다 필요한 모든 정보를 주기 때문입니다. REST에서는 상태가 서버가 아니라 클라이언트에 유지되며 매 요청마다 필요한 정보를 서버에 보냅니다. 이렇게 하면 쉽게 북마크 할 수 있습니다.

마지막 넷째로 Uniform interface : Use the standard methods of the protocol

-모든 Resource는 일반적 http인터페이스인 GET, POST, PUT, DELETE로 접근되어야 합니다.

위의 4가지 특성 때문에 좀더 빠른 웹서비스를 제공할 수 있습니다.

 

4. 다음은 REST의 장점과 단점을 살펴보겠습니다.

장점으로  

 

a. 기존의 웹 인프라를 그대로 이용할 수 있습니다.

가장 큰 장점중의 하나일 것입니다. 기존 HTTP를 그대로 사용하기 때문에, 원격지원서비스를 할 때도 방화벽을 새로 뚫어야 하는 등의 요건이 없고, L4등의 로드 밸런서 장비들도 그대로 사용이 가능합니다.

b. 무엇보다 웹캐쉬 서버를 그대로 사용할 수 있습니다.

모든 Resource가 URI로 Unique하게 표현되기 때문에, 웹 캐쉬 상에 보관될 수 있고, 특히나SELECT성의 명령은 이 캐쉬에 의해서 실제 Biz Transaction을 타지 않고 바로 리턴 될 수 있기 때문에, 성능과 리소스 활용 측면에서 어마어마한 장점을 가지고 있습니다.

c. 쉽습니다.

웹 서비스와 비교해보면 웹 서비스는 스펙이 정말 많습니다. WS*-I, WS Reliable Messaging, WS Transaction 등등 스펙 덩어리다. 그러나 REST는 별도의 SPEC이 없습니다. 보통 Defector 표준이라고 하는데, HTTP URI와 Method만 잘 지켜서 사용하면 그게 REST입니다.

REST의 단점입니다.  

 

a. REST는 표준이 없다. 즉 관리가 어렵습니다.

REST가 요즘 들어 부각되는 이유 자체가 WebService의 복잡성과 그 표준의 난이도 때문에 Non Enterprise 진영 Google,Yahoo,Amazone등을 중심으로 집중적으로 소개되었습니다. 데이터에 대한 의미 자체가 어떤 비즈니스 요건처럼 Mission Critical 한 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 필요했지 Enterprise 수준의 표준도 필요하지 않았고,벤더들처럼 이를 주도하는 회사도 없었습니다.  

단순히 많이 사용하고 암묵적으로 암암리에 생겨난 표준 비스무리 한 것이 있을 뿐입니다. 이런 것을Defector 표준이라고 부릅니다.  

그런데 문제는 정확한 표준이 없다 보니, 개발에 있어서 이를 관리하기가 어려워진다는 것입니다. 표준을 따르면 몇 가지 스펙에 맞춰서 개발 프로세스나 패턴을 만들수 가 있는데, 이는 표준이 없으니, REST 기반으로 시스템을 설계하자면 사용할 REST에 대한 자체 표준을 정해야 하고, 어떤 경우에는REST에 대한 잘못된 이해로 인하여 잘못된 REST 아키텍쳐에 이건 REST다 라는 딱지를 붙이는 경우가 많습니다. 실제로 WEB 2.0의 대표 주자격인 Flickr.com도 REST의 특성을 살리지 못하면서 RPC 스타일로 디자인한 API를 HTTP + XML을 사용했다는 이유로 Hybrid REST라는 이름을 붙여서REST 아키텍쳐에 대한 혼란을 초래했습니다.

b. REST적인 접근과 설계가 필요합니다.

REST는 SOAP와 같은 프로토콜이 아닙니다. REST는 아키텍쳐입니다.Resource를 기반으로 하는 아키텍쳐이기 때문에 시스템 설계도 Rest 에 맞는 설계가 필요한 것입니다.

5 .REST를 한줄로 요약한다면,

REST는

1. 웹의 모든 리소스를 URI로 표현,

2. 이를 구조적이고 유기적으로 연결하고  

3. 비 상태 지향적인 방법으로

4. 일관된 method를 이용하여 리소스를 반환하는 아키텍쳐!!

라고 할 수 있습니다.

 

감사합니다.(_ _) 

 

 

[출처] [Web Service] RESTful하다는것, 편하다는것|작성자 가브리엘김