RESTful 웹서비스
작성자 : 김문규
최초 작성일 : 2008. 4. 2
인터넷 업계는 OpenAPI의 열풍이 불고 있다. 너도나도 OpenAPI를 공개하고 있고 사용자들에게 다양한 방식의 사용을 기대하고 있다. 최근 이 OpenAPI와 함께 거론되는 기술을 당연 REST이다. 구글, 아마존, 네이버 모두가 OpenAPI를 REST 방식으로 지원한다. (물론 기존의 SOAP 방식도 지원한다.)
그렇다면 REST란 과연 어떤것일까? W3C 표준이 아님에도 불구하고 업계의 사랑을 받는 이유는 무엇일까? 이 궁금증을 풀기위해 본 포스트를 작성하고자 한다.
1) 정의+ REST는 ROA를 따르는 웹 서비스 디자인 표준이다. - ROA : Resource Oriented Architecture
2) 주요 특징
+ REST 방식의 웹서비스는 잘 정의된 Cool URI로 리소스를 표현한다.무분별한 파라미터의 남발이 아니라, 마치 오브젝트의 멤버변수를 따라가듯이~
예를 들면 아래와 같다.
http://www.iamcorean.net/user/mk/age/32
기존의 서블릿을 이용한 URI는 대부분 이랬다.
http://www.iamcorean.net/finduser.jsp?user=mk&age=32
차이가 보이는가?
+ REST 방식의 웹서비스는 세션을 쓰지 않는다는 거다.
기존의 서블릿 개발에서는 세션을 이용해서 인증 정보들을 가지고 다닌다. 개발자의 개념(?)에 따라서는 파라미터까지 마구마구 집어넣어서 사용하기도 한다. 이 때문에 요청 처리가 너무너무 무거워진다.
또한 요청간의 전후 관련성이 생기기 때문에 한 세션의 일련의 요청은 무조건 하나의 서버가 처리해야 한다. 그래서 로드발란싱을 위해 고가의 로드발란싱 서버가 필요하게 된다.
하지만 REST는 세션을 사용하지 않기 때문에 각각의 요청을 완벽하게 독립적이다. 따라서 각각의 요청은 이전 요청과는 무관하게 어떠한 서버라도 처리할 수 있게 된다. 즉! 로드발란싱이 간단해 질 것이라는 것이 느낌이 오는가? (물론 인증 관련해서는 복잡한 문제가 생긴다.)
3) ROA의 정의+ ROA는
- 웹의 모든 리소스를 URI로 표현하고
- 모든 리소스를 구조적이고 유기적으로 연결하여
- 비 상태 지향적인 방법으로
- 정해진 method만을 사용하여 리소스를 사용하는
아키텍쳐 이다.
+ 이는 4가지의 고유한 속성과 연관되어 진다.
- Addressablilty
- Connectedness
- Statelessness
- Homogeneous Interface
+ 여기서 잠깐! 정리하자면 REST란 위에 언급한 4가지 속성을 지향하는 웹서비스 디자인 표준이다.
4) RESTful 웹 서비스 속성 (ROA 속성)+ Addressablilty (주소로 표현 가능함) - 제공하는 모든 정보를 URI로 표시할 수 있어야 한다.
- 직접 URI로 접근할 수 없고 HyperLink를 따라서만 해당 리소스에 접근할 수 있다면 이는 RESTful하지 않은 웹서비스이다.
- 예를 들면, GMail은 모든 메일 리소스는 하나의 URI와 연결되어 있다. (http://mail.google.com/mail/?hl=ko#sent/1036854d04d6de9e) 하지만 코리아닷컴의 경우에는 http://mbox07.korea.com/mail/mailView.crd 라는 주소에 접근한 후에 페이지에 표시된 메일의 링크를 통해서만 접근이 가능하다. (특정 회사를 지칭해서 유감입니다. 관계자 분들은 이해 부탁드립니다.) 둘 간의 차이가 이해가 되십니까?
+ Connectedness (연결됨) - 일반 웹 페이지처럼 하나의 리소스들은 서로 주변의 연관 리소스들과 연결되어 표현(Presentation)되어야 한다.
- 예를 들면,
<user>
<name>MK</name>
</user> 는 연결되지 않은 독립적인 리소스이다.
<user>
<name>MK</name>
<home>MK/home/</home>
<office>MK/office</office>
</user> 는 관련 리소스(home, office)가 잘 연결된 리소스의 표현이다.
+ Statelessness (상태 없음) - 현재 클라이언트의 상태를 절대로 서버에서 관리하지 않아야 한다.
- 모든 요청은 일회성의 성격을 가지며 이전의 요청에 영향을 받지 말아야 한다.
- 다시 또 코리아닷컴의 예를 들면 메일을 확인하기 위해 꼭 '..코리아닷컴../mailView.crd'에 접근하여 해당 세션을 유지한 상태에서 메일 리소스에 접근해야 한다. 이것이 바로 Statelessness가 없는 예이다.
- 세션을 유지 하지 않기 때문에 서버 로드 발란싱이 매우 유리하다.
- URI에 현재 state를 표현할 수 있어야 한다. (권장사항)
+ Homogeneous Interface (동일한 인터페이스)
- HTTP에서 제공하는 기본적인 4가지의 method와 추가적인 2가지의 method를 이용해서 리소스의 모든 동작을 정의한다.
- 리소스 조회 : GET
- 새로운 리소스 생성 : PUT, POST (새로운 리소스의 URI를 생성하는 주체가 서버이면 POST를 사용)
- 존재하는 리소스 변경 : PUT
- 존재하는 리소스 삭제 : DELETE
- 존재하는 리소스 메타데이터 보기 : HEAD
- 존재하는 리소스의 지원 method 체크 : OPTION
- 대부분의 리소스 조작은 위의 method를 이용하여 대부분 처리 가능하다. 만일 이것들로만 절대로 불가능한 액션이 필요할 경우에는 POST를 이용하여 추가 액션을 정의할 수 있다. (되도록 지양하자)
5) 정리REST는 . 웹의 모든 리소스를 URI로 표현하고 . 이를 구조적이고 유기적으로 연결하여 . 비 상태 지향적인 방법으로 . 일관된 method를 사용하여 리소스를 사용하는 웹 서비스 디자인 표준이다.
6) SOAP과 비교
< 사진 출처 : http://blog.hoons.kr/blog_post_22.aspx >
SOAP은 SOAP메세지를 이용하여 특정한 서비스를 요청한다. SOAP 메세지를 사용해야 하기 때문에 무겁다고 말하고 서비스를 요청하기 때문에 SOA와 가깝다.
REST는 URI를 이용해서 리소스를 요청한다. URI를 사용하기 때문에 가볍다고 말하고 리소스를 요청하기 때문에 ROA와 가깝다.
SOA와 ROA에 대한 관점은 시각에 따라 다를 수 있지만 극명하게 대조하기 위해서는 위와 같이 차이점을 이해하는 것이 가장 좋다고 생각된다.
7) 맺음말
최대한 쉽게 작성하고자 했지만 여전히 MK 본인에게도 설명하기 어려운 것은 사실이다. 하지만 중요한 것은 REST는 아키텍쳐가 아니라는 사실이다. ROA라는 아키텍쳐를 반영한 디자인 철학이다. ROA의 4가지 중요한 속성을 잘 이해한 후 이를 가슴에 깊이 새기고 이를 어기지 않고 웹 서비스를 디자인하면 이것이 바로 RESTful 한 웹 서비스가 될 것이라는 것이다. 다음 포스트에서는 REST 구현체들에 대해 생각해 볼 예정이다. .net, java, ruby on rails에서 각각의 접근 방식에 대해서 좀 더 구체적으로 알아보도록 하자.
댓글 없음:
댓글 쓰기