어디서 한번쯤 들어보지 않았는가. “RESTful 한 웹서비스를 만들어야 한다.”, “우리 웹 애플리케이션도 REST를 고려하고 만들어졌나요?” 머릿속이 복잡해져 다시 REST가 무엇이냐 물어보면 우물쭈물 명확한 대답은 안 나온다. 자기들도 확실히 모르는 개념을 웹 서비스에 적용하라고?

진정하자. 지금부터 무엇인지 알아갈 것이다. 복잡할 것 없이 REST는 일종의 웹 서비스 설계 기준일 뿐이다. 가이드라인이 존재하고, 그것을 준수해 웹 애플리케이션을 만들었으면 그게 RESTful한 웹 서비스가 되는 거다!

쓰면 어디에 좋나요?

REST 아키텍처는 이미 전 세계에서 사실상 표준으로 자리잡았다. 다시 말해, 어떤 OS/브라우저를 사용하던 모두 커버할 수 있는 범용성이 보장된다는 소리다. 십수년 전에는 IE만 지원하면 장땡이였지만, 지금은 메이저 PC 브라우저도 훨씬 많고 심지어 모바일 환경도 존재한다. 이 많고 많은 환경을 일일히 따로 설계해 지원할 것인가? 별로 좋은 생각은 아닌 것 같다. 주민등록 주소지를 회사 사무실로 새로 신고해야 할 수도 있다.

REST 가이드라인을 따르면 위와 같은 참사를 피할 수 있다. 내 시스템 디자인을 명확하게 확립할 수 있게 해주고, 여러 기기에서 모두 사용할 수 있는 범용성도 보장할 수 있다. 나머지 이점들은 아래 특징들과 함께 살펴보도록 하자.

특징

위키피디아의 REST 문서를 살펴보면 이것저것 외계어가 적혀 있다. 물론 전부 알아두면 좋지만, 당장 끌어올 뇌 리소스가 부족한 분들은 아래 핵심 개념 2가지만 살펴봐도 충분하다.

URI는 직관적, 그리고 의미 중복 없이 정보(자원)을 가르켜야 하고, 모든 상호작용은 HTTP 메소드를 사용해야 한다.

먼저, 맨 앞의 ‘URI‘는 ‘URL’의 오타가 아니다. URI는 URL을 포함하는 상위 개념 정도로 보면 된다. 기존 우리가 알고 있던 URL의 역할처럼, 온라인 상의 무언가를 가르키는 주소다. 예를 들어, https://www.google.com 은 URI이면서 URL이다. 아직까지는 이해가 잘 안될 것인데, 다른 예시를 하나 더 가져와 보겠다. https://www.google.co.kr/search?q=uri 주소의 /search 까지가 URL, 그리고 ?q=uri(쿼리스트링) 부분은 ‘URN‘이다. 외계어를 하나 더 꺼내와서 미안하다. URN도 마찬가지로 URI의 하위 개념 중 하나이다. 그리고 방금 예시로 보여준 주소처럼, URL + URN = URI가 되는 것이다. 조금 빙 돌아온 느낌이 없잖아 있는데, 대충 URI가 무엇인지 느낌이라도 알았다면 성공한 거다.

이제 뒷부분을 보자. ‘모든 상호작용은 HTTP 메소드를 사용해야 한다’ 라고 했는데, 여기서 ‘HTTP 메소드‘는 어쩌면 익숙할 수도 있는 GET, POST, DELETE 등을 뜻한다. 여기서 일일히 메소드들의 종류를 전부 나열하지는 않겠다. 대신 위 링크에 들어가 자세한 메소드, HTTP 응답 코드 등을 살펴보길 바란다.

아래 RESTful한 HTTP 메소드 예시는 이곳을 참고했습니다. 작성자님 감사합니다.

아래는 바람직하지 않은 글 목록에서 5번 글을 받아오는 GET 메소드 예시이다.

GET /posts/show/5

영 좋지 않다. HTTP 메소드 GET은 이미 정보 검색을 서버에 요청하는 기능을 담고 있는데, 또 URI에 show라는 동사를 넣어 ‘보여준다’ 라는 의미를 중복시킬 이유는 없다. 위 URI는 아래처럼 수정할 수 있다.

GET /posts/5

깔끔하고 좋지 않는가? 직관적이고 의미 중복도 없어졌다.

마치며

“엥? 이게 끝이야?” 라고 물어볼 수도 있을 거다. 예. 끝입니다. 이 글의 취지는 REST 라는 개념을 이해하는 것이였지, 어떻게 당장 웹 애플리케이션을 RESTful하게 짤 수 있는지에 대한 글은 아니다. 어쩌면 나중에 다룰 지도 모르겠다. 그때가 되면 이곳에 링크를 달아 두겠다. 필자처럼 웹에 무한한 매력을 느껴 새로 홀려버린 분들을 위한 글이였다.