[dW리뷰]RESTful한 웹 서비스 만들기
원문기사: http://www.ibm.com/developerworks/kr/library/tutorial/j-rest/index.html
자바로 구현된 Restlet이라는 프레임워크로 RESTful Web Service를 개발하는 것에 대한 기사입니다.
REST란 무엇인가?
REST는 메시지라기보다는 이름이 부여된 자원, 예를 들어 URL(Uniform Resource Locator), URI(Uniform Resource Identifier), URN(Uniform Resource Name)과 같은 형태로 된 자원에 의존하는 느슨하게 결합된 웹 애플리케이션을 디자인하는 한 형식이다. 엄밀히 말해 REST는 이미 웹에서 검증되었고 성공적인 인프라스트럭처라 할 수 있는 HTTP에 올라탄 형태로 HTTP를 잘 이용하고 있다. 즉 REST는
GET과POST요청과 같은 HTTP의 단면들을 이용했다고 할 수 있다. 이같은 요청들은 표 1에 보인 것처럼 생성(create), 읽기(read), 갱신(update), 삭제(delete) 즉 CRUD라는 표준 비즈니스 애플리케이션의 요구 조건에 꽤나 잘 맞아 떨어진다.
REST에 대해서는 HTTP의 Method들을 다 활용하고 URL 규칙을 잘 해 둔거라고 막연하게만 알고 있었습니다만 기사를 통해서 정리된 내용으로 보니 좋네요. REST의 대한 정의와 URL 규칙이 중요한 부분이고 나머지는 일반적인 웹 서비스 개발과 다를 바 없습니다. Restlet으로 한번 따라해보기 좋습니다만 RESTful Service 구현을 위해서 Restlet 프레임워크를 꼭 사용할 필요는 없어보입니다. API 네이밍 규칙이 친숙해 보이는데 Rails에서 사용하는 네이밍 규칙이네요. Rails가 REST를 충실히 따르고 있는 것이었군요 ^^
RESTful Web Service로 개발했을 때 어느 정도는 성능상의 오버헤드가 있다고 생각됩니다만(웹에서의 고객 대상 페이지가 아닌 미들웨어로 사용했을 경우).. 기존 HTTP 인프라를 잘 활용할 수 있기 때문에 더 좋은 성능을 얻기 쉽다고 합니다. 사실 궁금한 것은 더 좋은 성능을 쉽게 보여주는 HTTP 인프라 예시인데요. 단순히 가장 많이 사용되기 때문에 그만큼 성능향상에 활용할 것도 많다는 의미인지, 아니면 REST의 디자인 자체가 성능 향상에 이상적이라는 것인지는 좀 애매합니다. 그리고 자원을 URL로 매핑시키는 것은 좋지만.. 해당 자원이 너무 규모가 큰 것이어서 자원의 일부만 보여주는 뷰로 접근해야할 경우는 REST로 어떻게 표현해야할지.. 뷰도 자원으로 생각하면 될까요? 그러면 뷰를 위한 파라메터가 URL에 이래저래 붙어서 깔끔한 REST를 유지할 수 없을 것 같은데요. 기사를 하나 읽으면 알아보고 공부할게 더 늘어나네요 -,.-
어쨌든 간결한 REST의 핵심을 간결하게 볼 수 있는 기사였습니다!
