게으른 자는 꿈만 꾸다 죽는다

출처: 오픈마루 블로그

마이크로소프트웨어 4월호에 ias님께서 쓰신 글이 Cover Story로 소개되었습니다.

지난번에는 스프링노트의 OpenAPI에 대한 기초적인 이야기를 했는데, 이 기사를 통해 Open API와 스프링노트 개발 스토리를 좀 더 구체적으로 다루게 되었습니다.

------

필자가 티맥스를 떠나 오픈마루로 오면서 꼭 해 보겠다고 다짐한 일이 있다. 2002년부터 4년간 웹 서비스(Web Services) 업계에 몸담으며 가장 절실했던 것은 다름 아닌‘사용’그 자체였다. 서블릿, JSP, EJB와 같기를 바라는 것은 무리겠지만, 열심히 만들어도 사람들에게 쓰이지 않는다는 현실에 적잖은 좌절을 맛본 탓이다.

왜 사람들은 SOAP를 써서 메시징을 하지 않을까? 왜 사람들은 WSDL로 인터페이스를 작성하고 공유하지 않을까? 왜 사람들은 UDDI로 서비스를 검색하지 않을까? 그 많은 WS-*는 다 어디 있는 걸까? 솔직히, 나는 2002년 웹 서비스 분야를 연구개발하면서 SOA(Service Oriented Architecture)와 더불어 SOAP, WSDL, UDDI와 WS-*는 JSP와 EJB처럼 널리, 그리고 흔히 쓰이는 기술이 되리라 예상(어쩌면 기대)했었다. 더군다나 웹 서비스 기술들은 자바나 닷넷처럼 개발 플랫폼에 국한되어 있지도 않으니 말이다.

하지만 웹 서비스가 근간으로 하고 있는 웹과 XML은 내 예상(이자 웹 서비스 업계 종사자들의 염원)을 멋지게 벗어나며 새로운 패러다임으로 이동하고 있다. 웹 2.0이라는 거창한 구호를 들지 않더라도, 범용 데이터의 전송 프로토콜(Transport Protocol)로 고안되지 않은 웹을 가장 흔히 쓰이고 방화벽에 친화적이라는 이유로 채택한 것은 오히려 비효율과 무방비를 거드는 격이 되었다. Ajax로 승화한 XML은 도리어 자바스크립트에 친화적인 JSON(JavaScript Object Notation)의 위협을 받고 있는 형편이다.

CORBA가 분산 시스템의 통합에 완전히 실패한 것은 아니다. 적어도 자바라는 걸출한 성공작의 밑거름이 되었으니 말이다. 게다가 이제는 이루지 못한 꿈을 웹 서비스, 더 구체적으로는 WS-로 시작하는 온갖 스펙(통칭 WS-*)으로 이루려 하고 있다. 메시지 지향(message oriented)건 RPC(Remote Procedure Call)이건 간에 분산된 데이터와 프로세스의 통합은 바벨탑처럼 높이높이 올라가고 있다.

웹, HTTP와 HTML은 웹 서비스와 대체 무슨 상관일까? 전송 프로토콜로 HTTP만을 고집하지도 않고, XML은 웹의 대표 형식도 아니다. 따라서 웹 서비스는 잘못된 명명이며, 차라리 XML 서비스라고 해야 그나마 적절하지 않을까(실제로 XML 웹 서비스라고 늘려 부르는 이들도 있다)? 이런 저런 생각을 하고나니 XML 서비스(SOAP, WSDL, UDDI, 그리고 WS-*)가 왜 웹에서 점점 멀어져가는 지를 이해할 수 있게 되었다. 그리고 나 자신도 2006년 Ajax를 접하기 전까지 왜 웹의 패러다임 이동을 감지하지 못했는지 납득이 되었다. 웹이 아닌 웹 서비스, 사그라지는 XML 열풍, 그때 나는 뒤를 돌아보았고, 조용한 반성을 지나 대안을 찾아 새로운 세상으로 발길을 돌렸다.

편안한 세상(RESTful World)

기대를 하지는 않았다. 그러나 SOAP과 WSDL만을 판 4년의 세월을 뒤로 한 채, 내가 맞닥뜨린 것은 생소함의 극치, 바로 REST(REpresentational State Transfer)였다. REST를 처음
들은 것은 2005년 아파치 컨퍼런스 유럽에서의 한 발표에서였다. 나중에 떠올려보니 발표자는 REST 주의자였는데, 당시 아마존의 웹 서비스에 있어 SOAP+WSDL 방식과 REST 방식의
사용 비율이 3:7 정도라고 했다. 발표장의 청중들은 수군댔다. 그 자리에는 SOAP 엔진과 WSDL 툴을 만들던 Axis2 팀이 있었기 때문이었다. Axis2 팀은 멋쩍게 웃어 넘겼고, 나도 실은 대수롭지 않게 여겼다. 그리고 2년 후 오늘날에는 더 이상 비교 자체가 무의미해지고 만다. 구글의 SOAP 기반 검색 API의 신규 가입 중단 소식과 함께 밝혀진 아마존 사용 비율은 REST가 95%라니, 한마디로 REST의 성장세는 뚜렷하다.

대체 REST는 뭘까? 솔직히 고백하면, 나는 최근까지도 REST를 깊이 살펴보지 않았다. 내가 그동안 쌓아온 REST의 이해는 다음과 같았다.

SOAP+WSDL가 오브젝트를 매개로 하는 행위(behavior)가 중심이라면, REST는 웹에 존재하는 리소스의 상태가 핵심이다. REST는 메시지의 형식이 자유롭다. 같은 리소스도 POX(Plain
Old XML-특정 스키마에 속하지 않는 평범한 XML), JSON, RSS와 ATOM 등으로 다양하게 표현할 수 있다.

하나의 리소스에 대해 CRUD(Create, Retrieve, Update, Delete - 만들고, 읽고, 고치고, 지우는 처리)를 HTTP의 메소드 POST, GET, PUT, DELETE와 대응하여 리소스의 URI (Uniform Resource Identifier, 보통은 웹 주소나 URL로 더 잘 알려져 있다)로 리소스를 요청하면 된다.

이 글은 REST를 소개하기 위한 것이 아니므로, REST 자체에 대한 분석은 다른 지면을 기약해야겠다. 다만, 여기서 REST에 대한 나의 상태가 변하게 된 에피소드를 하나 소개하고 싶다.
내가 일하는 오픈마루에서 이달(3월)에 공채 면접을 실시했다. 웹 서비스 팀에게는 면접 전 과제로‘REST vs RPC’에 대한 분석과 발표를 내었는데, 한 지원자의 발표에 REST를 명료하게 설명하는 것을 들으면서 문득 깨달았다.

‘Representation이 뭘까? Transfer는 왜 붙였을까?’

나는 REST라는 개념을 거부감 없이 받아들였지만, 실은 REST라는 이름만 능숙하게 사용할 뿐 왜 그런 이름을 붙였는지, 주요 개념이 무슨 의미인지에는 관심도 없었다. 심지어 Resource도 매우 직관적으로‘웹에 있는 리소스라면 웹에 있는 데이터겠지’정도로 생각하고 있었던 것이다.

REST에 대한 기본 개념 탑재가 제대로 되어 있지 않다고 판단한 나는, REST를 창시한 로이 필딩(Roy Fielding)의 박사 학위 논문“Architectural Style and the Design of NetworkbasedSoftware Architectures”을 읽기 시작했다(여전히 나는 면접 중이었고, 마침 노트북과 함께 있었다). 그 논문은 3장까지 비교적 일반적인 이야기로 토대를 다지다가, 4장에 이르러 웹의 아키텍처를 논하게 된다. 5장에서야 비로소 REST라는 용어가 처음으로 등장하며, REST의 기본 개념을 설파한다. 본문의 마지막 6장은 웹의 주요 구성 요소인 HTTP와 URI의 적용 등으로 마무리 짓고 있다. 2000년에 쓰인 논문이지만, 1993년부터 웹 표준 제정에 관여해온 저자의 웹에 대한 통찰력이 유감없이 발휘되며 지금 읽어도 웹 애플리케이션의 큰 그림을 그리는 데에 필요한 넓은 시야를 갖게 해준다.

REST의 Resource-Identifier-Representation은 마치 내용-이름-형식과 같은 존재론적 접근과 흡사하다. 웹에 어떤 정보가 있다. 누군가가 그 정보를 가리키려면 이름이 필요하다. 그리고 누군가에게 보여주려면 형태가 필요하다.

웹 애플리케이션에 이 구도를 투영해보면 더욱 그 의미는 가깝게 와 닿는다.

선로 위에서(On Rails)

지난 9월, 나는 스프링노트 프로젝트에 참가하기 시작했다. 1999년 웹 사이트 개발로 업계에 들어왔고, 2002년부터 4년간 웹 애플리케이션 서버라는 플랫폼 개발을 거
친 후, 다시 웹 애플리케이션 개발로 돌아왔다. 모든 것이 변해있었고, 많은 것이 새로웠다. 그리고 그 생경함의 중심에 레일즈가 있었다.

이미 마소에 여러 차례 소개된 레일즈. 나도 그 드높은 명성은 들어봤지만, 스프링노트 프로젝트 이전에는 본격적으로 할 기회가 없었다. 마침 레일즈 책 하나를 번역하게 되어(안타깝게도 아직도 출간을 못하고 있다), 피할 수 없으면 즐겨야 하는 상황과 맞물려 스프링노트 개발을 진행했다.

레일즈는 MVC 프레임워크이다. 다행히 플랫폼으로 진출하기 전에 MVC를 경험했던 나로서는, MVC 자체는 낯설 것이 없었다. 하지만 레일즈의 Convention over Configuration(이하
CoC) 철학은 명명(naming)에 대한 나의 기존 관념을 멋지게 박살냈다. XML 파일 설정(이제는 @으로 시작하는 어노테이션까지 포함)이 없으면 죽음을 달라는 식의 자바에 익숙했던 나는 한동안 이 CoC가 참으로 신기했다(지금은 당연하기 여기지만 ^-^; 언젠가 루비+레일즈 초짜였던 내가 프로젝트를 하면서 겪었던 일들을 책으로 써볼까 싶기도 하다).

여기까지는 레일즈와 REST가 아무런 관련도 없어 보인다. 반전은, 레일즈 1.2의 등장과 함께 한다. 스프링노트 팀의 강문식님(이하 별명인 deepblue)은 레일즈 1.2가 정식 릴리즈가 되기도 전에 레일즈의 소스 SVN 트렁크(현재 개발 버전)에 있는 레일즈 1.2의 REST 지원을 스프링노트 프로젝트에 도입했다. 레일즈 1.1.6의 표기법(convention)에 익숙해졌나 싶기 무섭게 레일즈 1.2는 RESTful(번역하기 참 까다로운 용어다. 그래서 아직 마땅한 말을 못 찾고 원어 그대로 쓴다) 웹 애플리케이션 개발을 위해 새로운 표기법을 제시했다.

간단히 비교해보면,
레일즈 1.1에서는 콘트롤러와 액션의 이름이 각각 URL로 대응되었다.

예) WelcomeController.hi -> /welcome/hi

레일즈 1.2에서는 이 방식과 더불어 RESTful 방식이 추가되었는데, 기본적으로는 모델과 모델 ID가 URL로 표현된다.

예) Page -> /pages 또는 /pages/1

기존 방식이 콘트롤러와 액션 주도적이었다면, RESTful 방식은 리소스(모델)와 오퍼레이션이 이끈다. 기본적인 오퍼레이션인 CRUD는 URL로 표현되지는 않고, HTTP의 메소드로 지정한다. 예를 들어 Page 목록을 얻어오는 오퍼레이션은 다음과 같다.

GET /pages -> PagesController.index가 호출됨

다음은 기본 오퍼레이션에 대한 URL 패턴과 대응하는 콘트롤러의 액션이다.

GET /pages -> PagesController.index
POST /pages -> PagesController.create
GET /pages/id -> PagesController.show
PUT /pages/id -> PagesController.update
DELETE /pages/id -> PagesController.destroy

이 같은 기본 오퍼레이션 이외의 오퍼레이션을 추가하는 경우, 그에 대한 URL은 레일즈 고유의 표현법과 동원된다. 예를 들어 PagesController에 export 액션을 추가한다면,

GET /pages/1;export

와 같이 URL의 맨 뒤에 세미콜론(;)을 구분자로 하여 액션을 붙이면 된다(어떤 HTTP 메소드(위에서는 GET)에 허용할지는 설정할 수 있다).

RESTful 레일즈에 대해서는 이 정도로 언급하겠지만, 모델과 액션을 구현했을 뿐인데 RESTful하게 되는 자연스러움은 독자에게 전달되었기를 바라며, 다음 이야기로 넘어간다.

테르모필레 협곡(뜨거운 문)

최근 개봉한 영화‘300’에서 스파르타 전사 300명이 목숨을 걸고 지키는 곳이 바로 테르모필레 협곡이다. 실은 지금 다룰 주제가 보안이라서 떠올렸는데, 그만큼 지키기 어려운 것임을 나타
내기도 한다.

스프링노트는 두 종류의 리소스-페이지(Page)와 첨부(Attachment)에 대한 OpenAPI를 제공한다. 기본적으로 CRUD가 가능하므로 읽기뿐만 아니라 쓰기도 할 수 있는 셈이다. 게다가 스프링노트는 근본이 개인 콘텐츠이므로 비공개가 기본이며, 협업을 위한 읽기, 쓰기 권한을 협업 사용자별로 설정할 수도 있을 정도로 보안에 매우 민감한 정보이다. 이미 공개된 네이버나 다음의 Open API에서는 비슷한 스펙을 찾을 수 없어(대부분의 API가 사용자 구분이 필요 없는 검색 쪽이다) 어떻게 보안 시스템을 짜야 할지 고민스러웠다.

물론 해외의 상황은 조금 더 참고가 많이 되었지만, 이번에는 예상치 못한 문제에 부딪혔다. 바로 OpenID였다. OpenID는 기본적으로 HTML을 입출력하고 HTTP 프로토콜을 소화하는 에
이전트, 즉 현실적으로는 웹 브라우저를 기반으로 하는 인증 기법이다. 그런데, Open API를 이용하는 매쉬업 애플리케이션의 종류가 웹 애플리케이션이 아닌 경우, 달리 말하면 독립형
(standalone) 애플리케이션은 지원하기가 수월치 않다(이 주제에 대해서는 다음 기회에 더 파고들고 싶다).

스프링노트 프로젝트는 12월부터 WoC(Winter of Code) 프로그램을 통해 세 명의 학생들과 매쉬업 개발을 병행했는데, 따라서 스프링노트 API는 그때부터 학생들을 통해 테스트되기 시작했다. 그때 처음 썼던 인증 방법은 단순히 사용자 키를 발급하여 HTTP 헤더에 넣어 보내는 것이었다.

이 방식은 URL 파라미터에 사용자 키를 붙이지 않아 직접적인 노출의 위험이 없고(물론 네트워크 전송 패킷을 가로채면 어쩔 수 없다), 서버 쪽 인증이 단순해서 한동안 쓰였었다.

하지만, 너무도 간단하고도 사용자 키가 사실상 사용자 암호 수준의 보안 정보이기 때문에 유출되었을 때 치명적이므로 보완이 필요했다. 여러 가지 방식을 모색하던 중, ATOM 인증 방식
에 대한 글로부터 영감을 받아 도입에 이르렀다. 이 방식은 키를 그냥 보내지 않고 다이제스트(digest)를 해서 보내며, 요청 메시지 생성 시간을 다이제스트에 포함하여 다이제스트가 유출되더라도 일정 시간이 지나면 효력이 없도록 할 수 있다는 장점이 있었다. 더불어 HTTP 헤더를 조작할 수 없는 일부 웹 가제트 플랫폼의 API에서도 인증을 할 수 있도록 키 다이제스트를 요청 쿼리의 파라미터로 넘기게 했다.

점차 스프링노트 API를 정립해가면서, 매쉬업 애플리케이션에 대한 등록과 관리가 필요함을 깨닫게 되었다. 사용자 키와 혼란을 줄 수 있지만, 정확히 말하면 사용자 키와 별도로 애플리케이션 키를 도입하여 애플리케이션에 대한 인증을 더한 것이었다. 매쉬업 사이트나 매쉬업 독립 애플리케이션이 과도한 요청을 하거나 불법적인 API 사용을 하는 경우(예를 들어 사용자 키를 악용한다거나 미풍양속을 저해하는 콘텐츠의 유입에 사용되거나) 제재하기 위한 수단이기도 하다.

두 개의 키를 사용함과 동시에 1세대의 HTTP 헤더와 2세대의 요청 쿼리에 이어 3세대에서는 HTTP의 표준적인 인증 방식 중 가장 기초적이라 할 수 있는 Basic Authentication 방식을 채택했다. 이 방식은 Authorization이라는 이름의 HTTP 헤더로 사용자 정보를 서버에 전달하여 인증 받는 방식인데, 이때 Base64라는 평범한 인코딩으로 사용자 이름과 암호가 전달되므로 암호대신 2세대에서 쓰인 다이제스트 값을 쓰도록 했다.

실제 오픈으로 치달으면서 점차 진화하는 스프링노트 API의 보안 시스템은 여전히 현재진행형이다. 일반 사용자가 OpenID 인증 정보 이외에 스프링노트라는 서비스에 특화된 사용자 키를매쉬업 사용에 반드시 써야 한다는 점은 다소 매쉬업 사용에 장벽이 될 지도 모르겠다. 그래서 4월부터는 3세대를 보완하는 OpenID 기반 API 인증 방식을 구축하려고 계획하고 있다.

천의 얼굴을 가진 스프링노트

스프링노트 API를 만드는 작업에서 레일즈의 덕을 본 RESTful 웹 애플리케이션 아키텍처는 속된 말로‘날로 먹었다’라고 한다면, 인증 시스템은 고민의 연속이었다. 그런데, 오픈이 임박해오면서 스프링노트 API가 전반적으로 정리되어 가자 불현듯 새로운 문제가 떠올랐다.

스프링노트의 기본 정보 단위인 페이지의 콘텐츠는 XHTML(정확히는 XHTML 1.1 Basic) 형식이다. 스프링노트의 페이지보기 화면은 콘텐츠뿐만 아니라 편집과 이동에 필요한 다양한 정보를 담고 있지만, 콘텐츠만을 보기 위한 XHTML 링크도 제공하고 있다.

<화면 1> 모든 페이지에 달려 있는 XHTML 링크(오른쪽 하단)

마치 RSS 버튼처럼 보이는 이 링크가 사용자에게 주는 것은 페이지 콘텐츠 그 자체이다. 물론 스프링노트의 DB에는 <body>태그 안의 내용만이 저장되며, 완전한 XHTML을 만들기 위해 <head>는 그때그때 생성된다.

여기까지의 논리를 따라오면, 스프링노트의 페이지는 일반적인 사용에서의 화면과 페이지의 내용만을 보여주는 화면, 즉 표현(Representation)이 두 가지인 셈이다. 리소스는 원래 표현이 자유로우니까, 가치 전달의 차원에서 표현을 평가한다면 기본 표현은 편집, 조직화(organization)와 이동(navigation) 등의 편이성을 제공해준다.

XHTML 표현은 리소스를 가감 없이 그대로 보여주므로 웹 클립이나 iframe 포함 등으로 편리하게 쓰일 수 있다. 여기에 스프링노트 API로 리소스를 접근하는 경우, XML과 JSON을 지원
한다. 이때는 두 표현 모두 페이지의 메타데이터라 할 수 있는 이름과 생성일자, 작성자 등의 정보와 콘텐츠가 같이 전달된다. JSON은 자바스크립트를 기반으로 하는 매쉬업 플랫폼(대표적으로 MS 가제트와 구글 가제트)에서 쓰기 편하며, XML은 그동안 다져온 저변을 무시하기 힘들다. 한 가지 흥미로운 움직임은 굳이 자바스크립트가 아니더라도 XML에 비해 가볍고 간단한 JSON이 다양한 프로그래밍 환경에서 두루 호응을 받아가고 있다는 점이다.

그런데, 생각해보면 XHTML은 오롯이 콘텐츠를, XML과 JSON은 콘텐츠와 메타데이터를, 그렇다면 메타데이터만 제공하는 표현은? RSS나 ATOM과 같은 형식도 있겠지만, 그 근원에는 HTML과 XML의 아버지 팀 버너스 리가 꿈꾸던 시멘틱 웹의 표준, RDF(Resource Description Framework)가 있다. RDF는 그야말로 뼈대이므로, 리소스의 메타데이터를 정형화하는 스키마가 RDF 위에서 필요로 하는데, 대표적인 것이 더블린 코어(Dublin Core, 이하 DC)라고 하는 표준이다. 원래 도서관의 서적 분류에 RDF를 사용하기 위한 세계 공동의 노력으로 시작한 DC는 스프링노트의 XHTML 콘텐츠에 대한 메타데이터 제공에 제격인 표현이라 할 만하다. DC는 XHTML의 <head> 태그 안에 <meta> 태그로 포함될 수도 있고, 따로 RDF 파일로 제공하고 XHTML에서는 링크로 연결될 수도 있다. 다만, DC 사용이 아직 낯설고 DC의 스키마가 RSS나 ATOM 같은 대중적인 형식에 비해 스키마가 복잡하다는 점이 걸림돌로 작용할 가능성이 있다.

한편으로는 DC의 채택이 가져다주는 장점을 살펴보지 않을 수 없다. XML과 JSON 표현은 모두 루비로 작성된 모델 클래스의 속성을 그대로 레일즈의 직렬화 규칙에 따라 나타내는 것이므로, 달리 재정의를 하지 않는 이상 프로그램 코드가 너무도 투명하게 바깥에까지 비친다는 문제가 있다. 사실 투명성 자체가 문제라기보다는, 공개적으로 사용될 인터페이스가 내부 프로그램 코드로부터 나왔다는 것은 의존성을 암시하며, 따라서 내부 프로그램이 바뀌면 외부 인터페이스도 바뀌거나 호환성을 위해 변환 과정을 거쳐야 하는 등의 부조리가 발생할 소지가 있다.

달리 말하면, 애플리케이션 개발자에게 제공할 인터페이스의 공공성이 부족하다고 할 수 있다. 표준은 바로 이런 취약점을 보완해주며, 더 많은 사람들의 동의와 도움을 구할 길을 열어준다. 이번 스프링노트의 API를 설계하면서 그 중요성을 크게 깨달았지만 부족한 점이 많다는 생각이 든다. 앞으로도 Open API의 설계에 있어 편리할 것과 표준에 근거할 것, 웹의 본질을 지킬 것,특정 프로그래밍 언어나 프레임웍에 얽매이지 말 것 등과 같은 원칙을 갖고 지속적으로 고민해야 할 것이다.

API는 개발 툴, 스프링노트는 DB

아무리 API가 잘 되어 있어도 그걸 쓰는 애플리케이션이 없으면 그야말로 아무 소용없다. 서비스와 동시에 Open API를 제공하는 시도에 있어 매쉬업의 부재는 Open API에 관심 있는 사람들에게 마치 칠흑 같은 어둠처럼 느껴질 것이다. 매쉬업에는 여러 가지가 있을 수 있지만, 여기에서는 크게 독립형 애플리케이션과 웹 애플리케이션으로 나눠 설명하고자 한다.

독립형 매쉬업

독립형 매쉬업이 웹 매쉬업과 구분되는 가장 큰 특징은 설치해서 쓴다는 점이다. 설치가 필요 없는 웹 매쉬업의 장점도 분명 있지만, 자신의 PC에 설치해서 쓰는 이점은 독립형 매쉬업의 성장을 이끌고 있다. 가젯(윈도우 비스타 사이드 바나 구글 데스크탑 등)이나 위젯(야후 위젯이나 맥 대시보드 위젯 등)은 작지만 요긴한 기능으로 사용자들을 즐겁게 해준다.

스프링노트 API를 쓴 독립형 매쉬업으로 가제트와 브라우저 툴바가 공개될 예정이다. 학생들이 겨울 방학이라는 짧은 기간동안 짬을 내어 만든 만큼 전문 개발자의 수준을 바라기는 어렵
지만, 오픈 소스 프로젝트로 이루어진 만큼 활용의 길은 넓게 열려 있다. 특히 스프링노트 API의 호출이나 인증 구현에 대한 실제 예시로써 도움이 많이 되리라 믿는다.

웹 매쉬업

독립형 매쉬업이 설치형 애플리케이션이라면 웹 매쉬업은 스프링노트 API를 활용하여 만든 웹 애플리케이션이다. 내가 처음 만든 스프링노트 웹 매쉬업은 현실적인 필요에 의해 만들었다. 스프링노트는 완전 GUI 에디터를 제공하여 문서 작성이 매우 직관적이고 기존 편집기의 노하우를 무리 없이 응용할 수 있지만, 대상 콘텐츠가 XHTML이라는 점에서 소스를 직접 다룰 수 없다는 면이 아쉽기도 하다. 사실 필자는 스프링노트를 Ajax 플랫폼으로 사용하려고 했다. 무슨 소리인고 하니, 스프링노트 페이지에 자바스크립트를 넣어 실행할 수 있으면 경량 MVC 플랫폼이 될 거라는 생각이었다. 모델에 해당하는 데이터도 XHTML 형식으로 페이지에 저장하고, 뷰는 XHTML 그 자체고 컨트롤러를 자바스크립트로 작성하면 되겠다고 생각했었는데, 금방 눈치 챌`수 있다시피 이 방법은 보안에 매우 치명적이다.

그래서 스프링노트 페이지의 소스를 직접 편집하고 그 안에 들어있는 자바스크립트 코드를 실행할 수 있는 웹 애플리케이션을 만들어 보았다. 특별히 서버 측 웹 애플리케이션 실행 환경이 없이도 웹 애플리케이션을 짜고 돌려볼 수 있다는 특징이 있다. 또, 스프링노트 페이지 콘텐츠로 <javascript> 태그는 들어가지 못한다(넣어도 지워진다). 따라서 <div id=”javascript’>와 같이 저장한 다음 매쉬업에서 <javascript>로 변환하여 실행하는 꼼수를 부린다.

스프링노트의 페이지를 계층적으로 구성할 수 있다는 점도 매쉬업의 응용에 매우 매력적이다. 레일즈의 ActiveResource 프레임워크를 쓰면 자체 DB가 없이도 스프링노트의 페이지 저장 공간을 활용에 게시판을 만들 수 있다. 예를 들어 분당 지역의 맛집 소개 게시판을 만들어서, 식당별 음식들을 나열하고 사진을 보여주며 지도 API와 엮어 약도를 보여준다. 스프링노트 서비스 자체에서는 소화해낼 수 없지만, API를 활용하면 얼마든지 원하는 화면 구성이 가능하다.

앞서 소개한 두 매쉬업은 앞서 소개한 가젯과 툴바처럼 예제로 서비스 오픈과 더불어 공개할 예정이다.

마음이 통하는 노트

스프링노트 API 자체의 사용법(스프링노트 공식 사이트를 통해 개발자 커뮤니티에 들어오면 API 설명과 애플리케이션 등록, 각종 예제 소개 등 자세한 안내를 받을 수 있다)을 소개하는 대신 스프링노트 API를 만들면서 거쳐 온 여정을 지면에 펼쳐 놓은 이유는, 그간 OpenAPI의 사용에 초점이 맞춰진 현실에 대한 균형과 더불어 웹 API 개발에 대한 관심과 실행에 부족하게나마 도움이 되고 싶어서이다.

스프링노트 프로젝트의 결과물 스프링노트가 일반 공개를 눈앞에 두고 있다니 가끔은 실감이 나지 않을 때가 있다(이 글을 쓰는 시점인 3월 중순에는 베타 테스트중이다). 스프링노트가 이제 시작이듯이 스프링노트 API도 이제 시작이다. 생각이 자라나는 노트를 바라는 스프링노트의 마음처럼, 스프링노트 API도 사용자와 개발자의 꿈이 펼쳐지는 플랫폼으로 자라기를 소망하며 다함께 스프링노트 API의 앞길(roadmap)을 그려 나가길 바라는 마음으로 스프링노트 API 제작기를 마친다.

자바에서의 REST - Restlet + JSR 311

자바는 일찍부터 XML과 웹 서비스 관련 API의 표준화에 투자해왔다. REST에 대해서도 JAX-WS 2.0에서 HTTP 바인딩과 함께 지원하지만, JAX-WS의 핵심은 SOAP+WSDL이었기에 그다지 관심을 받거나 쓰이지는 못했다.

Restlet은 이름에서 느껴지듯 애플릿(Applet)이나 서블릿(Servlet)처럼 RESTful 웹 애플리케이션 구성의 단위를 Restlet으로 정의하고 Restlet의 개발과 실행을 위한 스펙을 제공한다. 아직 자바 표준은 아니지만, 나름 참조 구현체(Reference Implementation)도 있는 오픈 소스 프로젝트다.

스프링노트 프로젝트의 초기에 잠깐 사용해본 Restle은, 서블릿의 프로그래밍 모델을 기반으로 REST의 개념에 매우 충실하다는 인상을 주기에 충분하다. JAXB나 JCR(Java Content Repository)와 연동하는 개발을 했었는데, API에 있어서도 부족함 없이 작업을 마칠 수 있었다. 현재 자바로 REST 스타일을 펼쳐보고 싶다면 Restlet은 매우 실용적인 대안이다.

한편, 최근 출범한 JSR 311 Java API for RESTful Web Services(이하 JSR 311)는 시작부터 아파치 쪽으로부터 따가운 시선을 받았다. REST의 창시자라고 추앙받는 로이 필딩은 아파치 창립자로도 유명한데, REST를 마치 표준처럼 스펙화 하려는(물론 자바에 국한된 것이기 는 하지만) JCP의 움직임을 매우 경계했다. 더불어 JSR 311의 아파치 참여를 보이콧(거부)하려고까지 했다. 다행히 JSR 이름과 API 패키지 이름에 REST(javax.rest와 같이)를 그대로 쓰지 않는 것으로 타협점을 찾았지만, 최근 썬이 Sun Web Developer Pack(http://developers.
sun.com/web/swdp/index.jsp)을 통해 Early Access라는 이름으로 RESTful Web Services API과 개발 환경을 배포하자 스펙도 내기 전에 비표준 API와 구현체를 내놓은 점에 대해 발끈하고 있다.

REST가 스펙이 아닌 스타일이라는 독특한 위치에서 비롯된 해프닝의 연속이었지만, 그만큼 REST에 대한 자바의 구애가 뜨거움을 느낄 수 있다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

• REST by 숏다리영감
• 일단 하나 끝나고. by decoder
• Domino XML Web Services-1 by meSsfilm
• Ajax 란? #1 by meSsfilm
• 에어콘 메타포를 이용한 WS-*와 REST 이야기 by Yozz