델리 키포스

최근 관심을 갖고 틈틈히 공부하고 있는 것이 REST(Representational State Transfer)입니다. REST는 아키텍처 스타일이라고 할 수 있는데 레일스 2에서 REST를 처음 접하게 되었습니다. 아키텍처 레벨은 REST를 기반으로 구현 레벨은 MVC로 설계가 잡히면서 프레임웍이 훨씬 더 짜임새 있어 보였습니다.

좁은 의미에서 REST는 ROA(Resource-Oriented Architecture)라고 볼 수 있습니다. 마치 객체 지향에서 모든 것을 객체(클래스)로 정의하 듯이 ROA에서는 서비스내에 의미를 가질만한 요소들을 리소스(resource) 단위로 정의합니다. 그리고 리소스가 의미를 가지기 위해서는 리소스의 이름이 필요하며 그 이름을 URI라고 합니다. 참고로 URI와 URL은 같은 걸로 보면됩니다.

그런데 리소스만으로는 서비스의 모든 URI를 표현할 수 없습니다. 모든 내용이 그 내용을 보여주는 형식을 필요로 하듯이 리소스도 리소스를 보여주는 형식이 필요합니다. 리소스를 보여주는 형식을 리프리젠테이션스(representaions)라고 합니다. 그리고 URI는 리소스와 리프리젠테이션의 조합으로 만들어집니다. 예를 들어 레일스에서 아래와 같은 URI 관례가 있습니다.

• /orders
• /orders/1
• /orders/new
• /orders/1/edit

‘/orders’과 ‘/orders/1′처럼 리소스만으로 표현된 URI가 있는가 하면 ‘/orders/new’와 ‘/orders/1/edit’처럼 리소스와 리프리젠테이션이 조합으로 구성된 URI도 있습니다.

일반적으로 리소스를 대상으로 할 수 있는 기본적인 조작(operation)은 몇가지 정해져 있습니다. 흔히 이것들을 CRUD(Create, Read, Update, Delete)라고 하며 레일스에서 정해놓은 CRUD 관련 URI는 아래와 같습니다.

• List : GET /orders
• Create Form : GET /orders/new
• Create : POST /orders
• Read : GET /orders/1
• Update Form : GET /orders/1/edit
• Update : PUT /orders/1
• Delete : DELETE /orders/1

여기서 주목할만 것은 Create, Update, Delete의 경우 별도의 URI를 갖지 않으며 리소스 URI를 요청하는 방식(method)를 달리 가져갔다는 점입니다. 리소스를 GET으로 요청하면 해당 리소스의 리프리젠테이션을 기대하게 되며 리소스를 POST로 요청하면 해당 새로운 리소스를 추가합니다. 마찬가지로 리소스를 PUT으로 요청하면 해당 리소스를 수정하는 것이며 DELETE 방식으로 요청하면 삭제하는 것을 의미합니다.

이러한 기본 규칙을 통해서 URI는 통일성을 가지게 됩니다. 그리고 이 통일성을 좁은 의미에서 RESTful이라 할 수 있습니다. 나아가 이러한 통일성은 개발 효율로 이어집니다. 새로운 서비스의 API를 접할 때 그 서비스가 RESTful하다면 URI의 기본 규칙이 동일하기 때문에 API 학습량이 줄어들기 때문입니다. 아마도 이러한 점이 관례를 중시하는 레일스가 적극적으로 REST를 도입한 이유가 아닐까 싶습니다.

그런데 서비스 기능 중에는 기본적으로 정의된 CRUD 이외의 것들이 있을 수 있습니다. 예를 들어, 단순하게 주문 목록을 보여주는 기능을 List라 하고 목록과 달리 주문과 주문 품목을 함께 보여주는 기능을 Inquiry라고 정합니다. 이때 Inquiry 리프리젠테이션의 URI는 아래와 같이 2가지로 생각해볼 수 있습니다.

• GET /orders?view=inquiry
• GET /orders/inquiry

앞에 것은 쿼리스트링에 리프리젠테이션(view) 정보를 넘기는 경우이며 뒤에 것은 URI에 리프리젠테이션을 명시한 경우입니다. 사실 어느 것으로 하던 상관은 없다고 봅니다. 다만 앞의 것의 경우 List와 Inquiry가 동일하게 주문 목록을 보여준다는 쪽에 무게를 실은 반면에 뒤에 것은 둘이 서로 다른 리프젠테이션이라는 것을 조금 더 명시적으로 표시한 것입니다. 저희 팀의 경우 뒤에 방식을 선택했는데 사용자들이 보기에 List과 Inquiry은 서로 다른 페이지라고 느낄 것이라고 판단했기 때문입니다.

지금까지 REST를 공부하면서 익혔던 것들을 정리해보았습니다. 참고로 RESTful Web Services을 보고 있는데 아직 중간 쯤 읽은 상태라 정리한 내용 중에 틀린 부분이 있을 수도 있으니 기회가 되면 덧글 좀 남겨주세요~

rest, restful, uri, url, 레일스

현재 루비(Ruby 1.8)는 유니코드(unicode)를 지원하지 않습니다. 저도 처음에는 일본 사람이 만들었으니 당연히 지원할 것이라고 생각했는데 그렇지 않더라구요. 대충 찾아보니 이런 사연이 있더군요.

아무튼 루비가 유니코드를 지원하지 않기 때문에 UTF-8 형식의 문자열을 자를 때 문제가 생깁니다. 루비의 String은 한 글자를 1byte 단위로 처리하는 반면 유니코드는 한 글자가 1byte 이상이기 때문입니다.

우선 루비의 경우 유니코드 관련 클래스가 있더군요. 여담으로 해당 모듈을 만든 사람이 노경윤이라는 사람인데 이분이 <레일스와 함께하는 애자일 웹 개발>의 번역자 중 한명이 아닐까라고 추측 해봅니다ㅎ

그런데 설치도 귀찮고 해야하고 조금 더 찾아보니 레일스(Rails)의 경우 멀티 바이트 문자열 확장팩이 있더군요. 다행입니다~

그리고 루비 1.9에서는 유니코드를 지원하더군요 ㅎ

레일스, 루비, 유니코드

현재 저희가 진행하는 프로젝트에서 jRails라는 레일스 플러그인을 사용하고 있습니다. 레일스는 초기부터 ajax를 지원했는데 클라이언트 쪽 기본 자바스크립트 프레임워크를 Prototype과 Scriptaculous를 사용하고 있습니다. 그런데 개인적인 Prototype과 Scriptaculous를 선호하지 않는 편입니다. 우선 Prototype의 경우 객체지향적이지 않으며 Scriptaculous까지 포함할 경우 파일의 크기가 커서 너무 무겁기 때문입니다.

그래서 평소 jQuery라는 자바스크립트 프레임워크를 눈여겨 보고 있다가 이번 프로젝트에 적용해 보았습니다. 참고로 이전 프로젝트에서는 Mootools라는 프레임워크를 사용했습니다. 당시 Prototype이 객체지향적이지 않은 점에 불만을 느끼고 대안을 찾던 중에 눈에 들어온 프레임워크입니다. 잘 기억은 안 나지만 Mootools에서 jQuery로 넘어온 이유는 당시 Mootools라는 프로젝트가 한두명(?)에 의해서 유지되었기 때문에 소스 및 프로젝트 관리가 너무 임의적이라는 판단했던 것 같습니다.

레일스 2에서도 기본 프레임워크가 Prototype이기 때문에 jQuery를 바로 사용할 수는 없으며 jRails라는 플러그인을 설치해야 합니다. 설치 내용을 살펴보면 우선 public/javascript 폴더에 jQuery 관련 파일들을 추가합니다. 참고로 jRails 0.4 버전에서는 jQuery 1.2.6을 버전을 지원합니다. 그리고 PrototypeHelper 모듈에서 관련 함수 및 클래스를 변경합니다. 해당 내용은 lib/jrails.rb 파일에서 확인할 수 있으며 내용은 그리 복잡하지 않으니 시간 나면 한번 살펴보는 것도 좋을 것 같습니다.

요즘은 jQuery가 많이 유명해진 편이지만 아직까지 Prototype의 점유율이 더 높은 것은 사실입니다. 그래서 jQuery의 사용을 꺼리는 사람도 있을텐데 이 부분은 크게 걱정하실 필요가 없습니다. 우선 jQuery는 다른 자바스크립트 프레임워크와 같이 사용할 수 있도록 설계되었습니다. 그리고 레일스 3부터는 jQuery가 정식으로 포함될 예정이라고 하니 jQuery를 선호하시는 분들은 jRails를 관심을 가져보는 것도 나쁜지 않을 듯 합니다.

jquery, 레일스