 |
|
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라는 표준 비즈니스 애플리케이션의 요구 조건에 꽤나 잘 맞아 떨어진다.
표 1. CRUD/HTTP 간의 대응
| 애플리케이션 작업 | HTTP 명령 |
|---|
| Create |
POST
|
|---|
| Read |
GET
|
|---|
| Update |
PUT
|
|---|
| Delete |
DELETE
|
|---|
동사(verb)라고 볼 수 있는 이러한 요청들과 명사(noun)라 볼 수 있는 자원을 연결함으로써 행동(behavior)을 논리적으로 표현한다. 예를 들어 이 문서를 GET하고 저 기록을 DELETE하라 라는 식이다.
REST의 실질적인 아버지라 할 수 있는 로이 필딩(Roy Fielding)은 그의 박사 학위 청구 논문에서 REST가 강조하는 것은 "컴포넌트 상호 작용의 확장성, 인터페이스의 보편성, 컴포넌트의 독립적 배치, 상호 작용의 레이턴시(latency)를 줄이고 보안을 강화하며 레거시(legacy) 시스템을 캡슐화하는 중간 단계의 컴포넌트 역할"이라고 언급하고 있다(참고자료 참조). RESTful한 시스템을 만드는 건 어렵지 않으며, 시스템들이 고도로 확장성을 갖게 됨에 따라 동시에 하위 데이터들과는 느슨하게 연결될 것이다. 또한 이 시스템들은 상당히 훌륭한 캐싱(caching) 기능도 이용하게 된다.
웹에 있는 모든 것(페이지, 이미지 등)은 본질적으로 자원(resource)이다. 메시지가 아닌 이름이 부여된 자원에 REST가 의존하기에 애플리케이션 디자인 측면에서 볼 때 느슨한 결합이라는 게 쉽게 가능해지는데, 이는 하부를 떠 받치는 기술이 무엇인지 노출되지 않기 때문이다. 예를 들어 다음 URL을 보면 하부 기술에 관해 암시하는 바는 전혀 없이 자원을 표현하고 있음을 볼 수 있다: http://thediscoblog.com/2008/03/20/unambiguously-analyzing-metrics/
이 URL에서 보듯 "Unambigously analyzing metrics"라는 기사를 가리키는 자원을 표현하고 있다. 이 자원에 대한 요청은 HTTP GET 명령을 쓴다. URL이 명사(noun) 기반임을 주목하자. 동사(verb) 기반인 경우(동사 기반이란 이런 식일 것이다. http://thediscoblog.com/2008/03/20/getArticle?name=unambiguously-analyzing-metrics) REST의 원칙에 위배된다. getArticle 형태에 메시지가 들어있기 때문이다. 또한 새로운 자원을 HTTP의 POST 명령을 써서 포스팅한다고 상상해 보자(말하자면 http://thediscoblog.com/2008/03/22/rest-is-good-for-you/ 같은 기사). 동사 기반의 API, 즉 createArticle?name=rest-is-good-for-you나 deleteArticle?name=rest-is-good-for-you를 쓰면 된다고 상상할 수도 있겠으나 그런 식의 호출은 HTTP GET 명령을 마구잡이로 쓴 것이고, 대부분의 경우에서는 이런 식의 호출은 이미 시중의 제대로 된 HTTP 인프라스트럭처를 무시하는 것이다. 바꿔 말하면 이런 식은 RESTful하지 않다.
REST의 아름다움은, 자원은 어떤 것이든 될 수 있고 표현될 수 있는 방식도 다양하다는 점이다. 바로 전에 보았던 예에서 자원은 HTML 파일이었기에 응답 형식도 그에 따라 HTML이 될 것이다. 하지만 자원이 XML 문서이거나, 직렬화된 객체이거나, 혹은 JSON 표현법이었을 수도 있다. 그게 뭐든 상관없다. 중요한 건 하나의 자원은 이름이 부여된다는 것 그리고 자원과의 통신은 자원의 상태에 영향을 주지 않는다는 것이다. 상태에 영향을 미치지 않는다는 것은 중요하다. 상태 없는(stateless) 상호 작용이 확장을 쉽게 해주기 때문이다.
왜 고민해야 하는가?
레오나르도 다 빈치의 말을 인용해 본다면 "단순한 게 가장 복잡한 것이다". 월드 와이드 웹의 구현은 단순하기 이를 데 없고 거부할 수도 없는 성공작이다. REST는 웹의 단순성을 사용했으므로 고도의 확장성을 만들어냈고 모두 알고 있다시피 만들기에 간단한, 느슨하게 결합된 시스템을 이끌어냈다.
앞으로 살펴 보겠지만 RESTful한 애플리케이션을 만드는 데 가장 어려운 일은 노출하려는 자원을 결정하는 것이다. 그것만 끝내면 Restlet 프레임워크를 써서 RESTful한 웹 서비스를 만드는 건 별 게 아니다.
| 
