REST에 대해 좀더 알아보기 전에, 일단 HTTP Method에 대해서 좀더 알아볼 필요가 있습니다. HTTP의 RFC 문서들을 보면, "Method"라는 것이 있습니다. REST에서 자주 사용되는 대표적인 메소드로 GET/POST/PUT/DELETE 를 꼽을 수가 있는데, 웹프로그래밍 경험이 있으신 분이라면 이 이름만 보고도 Method에 대해 감을 잡으실 것 같습니다. Web Request라는 것은, 웹서버에게 "URL"과, 거기에 어떤 "Method"를 사용할 것인지를 알려주는 것이라 볼 수 있습니다. 가령 다음의 예제를 보겠습니다.
커맨드 창을 띄우시고 텔넷으로 특정 웹서버에 접속해봅니다(위 예제에서는 www.jlab.net의 80포트에 접속). 최초에 웹서버에게 전달하는 인자가 "Method"가 되고, 두번째 인자가 "URL"이 됩니다. 즉 위 예제로부터 "www.jlab.net/index.html"에 "GET"을 적용하도록 웹 요청을 보낸 셈이 되는 것입니다. 웹브라우저에 www.jlab.net 이라고 엔터를 치면, 하부에서는 사실 위와 같은 요청이 만들어지는 것입니다(Host: 가 포함된 줄 이후는 HTTP response 부분이므로 무시하셔도 좋습니다.). HTML에서 Form 만들때 action 부분에 get/post 를 적게 되어 있는데, 이것에 따라서 웹브라우저가 Method로서 GET을 쓸지, POST를 보낼지가 결정되는 것입니다. 아시는 대로 GET일 때는 URL에 parameter를 인코딩해서 보내고 POST일때는 HTTP Body에다 parameter나 file 넣어서 보내고요.
바로 이 Method와 URL이 REST 인터페이스의 핵심 요소입니다. REST 인터페이스라는 것은, "웹서버에 존재하는 중요한 정보들을 리소스로 정의해서, 각 리소스에게 유일한 URL을 할당한 뒤, HTTP Method가 적용되었을 때의 의미를 정해두는 것" 이라고 이해할 수 있습니다. 꽤 추상적입니다만, 예제를 통해 좀더 구체적으로 이해할 수 있을 것 같습니다. 마침 REST 예제를 아주 잘 설명해둔 포스트가 있어서 링크 걸어둡니다. 이중 몇가지를 소개해 보겠습니다.
우선 Del.icio.us 라는 북마크 공유 사이트가 있습니다. 위 포스트의 저자는 이 사이트에 REST 인터페이스가 있으면 좋겠다 라고 이야기하고 있습니다. 그것을 어떻게 만들것이냐. 가령
1. "aUser" 라는 유저의 모든 북마크를 보고 싶으면
"GET http://del.icio.us/api/aUser/bookmarks"
2. "aUser" 라는 유저의 북마크를 추가하고 싶으면
"POST http://del.icio.us/api/aUser/bookmarks" 그리고 Body에다 새로운 북마크 정보
3. "aUser" 라는 유저의 북마크의 업데이트 시간을 알고 싶으면
"GET http://del.icio.us/api/aUser/bookmarks/update"
4. "aUser" 라는 유저의 특정 북마크 하나를 자세히 보고프면
"GET http://del.icio.us/api/aUser/bookmarks/[hash]"
5. "aUser" 라는 유저의 특정 북마크 하나를 수정하고프면
"PUT http://del.icio.us/api/aUser/bookmarks/[hash]" 그리고 Body에다 새로운 북마크 정보
6. "aUser" 라는 유저의 특정 북마크 하나를 삭제하고프면
"DELETE http://del.icio.us/api/aUser/bookmarks/[hash]"
참 쉽습니다! 1, 2를 비교해보면 URL이 동일하지만, Method가 다르므로 서로 다른 의미를 지니게 됩니다. 각 엔트리별로 hash 값을 이용해서, URL로 직접 접근할 수도 있고요. 이 경우 특정 클라이언트 프로그램 없이 바로 웹브라우저를 이용할 수도 있습니다. 왜냐하면, 이미 웹브라우저는 HTTP Method를 사용할줄 알기 때문입니다. 이전 포스팅에서 "RapidShare"가 REST 인터페이스를 써서 스토리지 서비스를 제공하는구나! 라고 말씀 드렸는데, 특별한 클라이언트 프로그램 없이도 웹브라우저 만으로 자료를 받을 수가 있게 되지요. 그 때 URL에 [hash]를 써서, 허가되지 않은 다른 사람이 쉽게 자료를 공유하지 못하기도 하고요. 물론 URL이 웹브라우저에 남아있을 수도 있고, 여러 보안문제도 있기는 하지만...
이게 뭐야, 새로운게 없잖아? 라고 생각하실 수 있을텐데 맞습니다. 별로 새로운 것 없습니다. 아주 당연해 보이는 듯한 원리, 그리고 무의식중에 누구든 써왔던 그런 기술들을 명시적으로 정리했다는 것만으로도 의미가 있는 것 같고, 이 기술은 Resource Oriented Architecture(ROA)라는 단어를 만들어냈지요(붐이 일었는지는 모르겠습니다만;). 그런데 URL을 구성하는데 있어서 좋거나 혹은 나쁜 예제들이 있습니다. 가령 위의 6번 예제를 "GET http://del.icio.us/api/aUser/bookmarks/delete/[hash]" 으로 정의해도 비슷한 효과를 보일수 있긴 합니다만, 이것은 '좋지 않은' 경우로 알려져 있습니다. 말하자면 '좋은 REST 인터페이스'를 만들기 위해서는 몇가지 규칙을 따라야 하는데, 그 규칙을 따르는 서비스들을 "RESTful Service" 라고 이야기 합니다. 다음 포스팅에는, RESTful Service에 대해 이야기해보겠습니다. 그리고 얼른 Google AppEngine로 가서 REST 서비스 구현까지 해보겠습니다.
덧글