Richard Mooney (Vordel)

This session answers two questions: Are REST Web Services inherently insecure? How can a  security model apply to both SOAP and REST Web Services?

REST방식은 제가 제일 선호하는 Open API 아키텍쳐 패턴입니다. 간편하고 Simple하고 따로 배울 필요가 없으며 비용 대비 효과가 크기 때문입니다. 실제 씽크프리의 Open API도 거의 REST 패턴을 따르고 있고 앞으로도 그럴 예정입니다.

Vordel의 아키텍쳐인 Richard Mooney 는 이러한 REST를 SOAP 비교하고 보안에 대해 세션에서 정리를 했습니다. 그냥 편안히 듣고 고개만 끄덕이고 말았네요^-^ 뭐 당연한 거니까…

실제 REST 방식에서 GET을 너무 heavy하게 사용하거나 서버의 상태를 변하게 하는 경우가 있다고 합니다. 그런데 사실 이런 경우는 설계가 잘못된것지 기술적인 문제는 아닙니다. REST의 설계 방법에 대해서는 제가 정리한 글을 참조하세요.

하여간  결론은 HTTP Query String을 믿지 말라는 것입니다!! 동감입니다. 뭐가 실려올지 어떻게 신뢰할지요! 따라서 기존의 웹 표준 방법을 REST에 적용해서 이를 신뢰하게 만들어야 합니다.

1)URL에 ACL을 걸어 권한을 체크한다.

2)SQL injection 처럼 URL QueryString에 문제 소지가 있기 때문에 이를 필터링하여 체크한다.

3)URL을 로깅한다. 아시겠지만 SSL을 걸면 자동으로 URL에 대한 로깅이 됩니다. 

4)아마존 등에서 사용하는 방법으로 Developer Token(Secret Access Key ID)을 사용하여 인증을 한다.

그런데 국내 포탈들의 Open API는 어떻게 개발되었나요? 크게 관심이 없어 볼 기회가 없었네요..누가 좀 알려주세요..

                                            REST Architecture

근래 들어 웹 개발 커뮤니티에서 가장 많이 사용하는 용어 중 하나가 REST( Representational State Transfer ) 일 것입니다. REST는 많은 웹2.0 회사들이 자신이 개발한 서비스를 외부에 공개하기 위한 Open API의 구현 방법으로 많이 사용되어 있습니다.  실제 구글, 플리커, 아마존 등의 Open API가 REST 방식으로 구현되어 공개되면서 급속히 확산되었습니다. 이러한 Open API 뿐만 아니라 REST는 서비스의 서버 플랫폼 구축에 있어 필수적인 아키텍쳐 입니다.  
 

아키텍쳐(Architecture)
일반적으로 소프트웨어 분야에서 아키텍쳐라 하면 컴포넌트와 데이터 그리고 이들 간의 인터페이스 등  S/W를 구성하는 요소들의 적절히 구성하고 배치하여 원하는 목적을 이뤄내는 것을 말합니다. 원하는 목적에는 기능 , 성능 , 확장성 등 다양한 이슈들이 포함될 수 있습니다.

REST 아키텍쳐(Architecture)

REST는 Roy Fielding 에 의해서 처음 사용된 용어로서 웹의 특성을 활용한 서비스 호출 Architecture를 말합니다. 좀 더 자세히 살펴보면 ,  
웹상이 모든 것들은 URL로  표현(Representation)됩니다. 이렇게 표현된 URL을 클릭하는 순간 다른 URL로 이동하게 됩니다. 이 과정을 달리 표현하면 해당 URL이 표현하고 있는 상태(State)에서 다른 URL의 상태로 이동(Transfer)하는 것입니다. 이렇게 잘 정의된 URL을 통해 웹 애플릿케이션을 구동시키고 그 결과(상태)를 전달(Transfer)받아 처리하는 것이 바로 REST 방식 입니다.

REST는 실제 표준은 아니지만 HTTP/URL/MIME Type같은 웹 표준을 사용한다. 따라서 실제 표준 기술이기도 합니다. 최근 Sun에서는 JRS311, Java API for RESTful Web services 을 발표하기도 했습니다.

REST에 대해 좀 더 실제 예를 들어 이해해보도록 하겠습니다.

가령, 아래 URL은 직원들의 명단을 조회하는 서비스입니다. 이 서비스를 통해 직원 명단을 받는 클라이언트는 서버측의 구현이 어떻게 되어 있는지 상관할 필요가 없습니다.

http://wisefree.com/employee

클라이언트가 이 서비스를 요청하면 다음과 같은 결과를 받게 됩니다.

<?xml version="1.0"?>
<p:Employee  xmlns:p="http://wisefree.com" xmlns:xlink="http://www.w3.org/1999/xlink">
<Employee id="603045"  xlink:href="http://wisefree.com/employee/603045"/>
<Employee id="741146" xlink:href="http://wisefree.com/employee/741146"/>
</p:Employee>

또한 클라이언트는 전달받은 직원 명단 중 603545번의 자세한 내용을 받기 위해 다음과 같이 REST 서비스를 호출합니다.
 

http://wisefree.com/employee/603045 

클라이언트는 다음과 같이 보다 자세한 결과를 받게 됩니다.

<?xml version="1.0"?>
<p:Employee xmlns:p="http://wisefree.com" xmlns:xlink="http://www.w3.org/1999/xlink">
<Employee-ID>741146</Employee-ID>
<Name>jisu park</Name>
<Resume xlink:href="http://wisefree.com/employee/741146/resume/"/>
</p:Employee>

이처럼 REST 방식은 "서버 주소 + 서비스 이름 + 자원" 으로 이루어진 URL을 호출하고 이에 대한 자원을 전달받으면서 서비스를 수행하는 구조입니다.
이러한 REST 방식으로 시스템을 디자인할 때는 다음의 사항을 주의해야 합니다.

- 제공하고자 하는 모든 conceptual 리소스(엔티티)들을 서비스로 제공합니다.

- 각 리소스들에 대한 URL을 설계합니다. 이 때, 주의할 점은 URL은 명사로 설계하며 서버 주소 + 서비스 이름 + 자원 방식으로 설계합니다.

http://wisefree.com/employee/getEmployee?id=603045 우울한 설계

http://wisefree.com/employee/603045 , 멋진 설계

- 이 때, URL을 통해 필요한 자원을 계속해서 추적하여 얻어(HTTP GET) 가거나 삽입(HTTP PUT), 삭제(HTTP DELETE)할 수 있게 분류 설계합니다. 결코 한번에 모든 정보를 제공해서는 안됩니다.

http://wisefree.com/employee 전체 직원 명단을 얻어 온다.

http://wisefree.com/employee/603045 특정 직원의 자세한 정보를 얻어 온다.(HTTP GET)

http://wisefree.com/employee/603045 특정 직원의 해당 정보를 갱신 온다.(HTTP PUT)

- HTTP GET을 통해 제공되는 모든 자원은 있는 그 상태의 정보를 제공하는 것이지 자원의 상태를 변경하고 그에 대한 결과를 제공하는 것은 아닙니다.

- 제공되는 결과는 Ajax등 RIA 기술을 사용할 경우 반드시 XML 포맷을 사용한다. 그 외의 경우에는 응용 프로그램의 상태에 따라 적절히 결정합니다.

자! 간략하지만 아주 중요한 사항들입니다. 개발자와 아키텍쳐 분들은 반드시 유의해 주길 바랍니다.