REST 기본 개념 총정리 2편 - REST의 6가지 제약조건 소개

이번에는 REST란 무엇인지를 알아보겠습니다.

1편인 REST의 등장 배경은 아래 링크를 참고해주세요!

https://dev-ws.tistory.com/71

REST 기본 개념 총정리 1편 - REST의 등장 배경

 

이전 편에서 언급했던 것처럼, 기존 WWW에는 몇가지 문제점들이 존재했습니다. 그리고 이런 문제를 해결하기 위해서 로이 필딩은 REST라는 개념을 제시했는데요.

 

그렇다면 REST는 무엇일까요? 정말 쉽게 정리하면 'WWW을 위한 제약조건의 집합'이라고 이해해도 될 것 같습니다. 조금 더 어렵게 이야기하면 '분산 하이퍼미디어 시스템을 위한 아키텍처 스타일'이라고도 이야기합니다. 그리고 이런 REST에는 총 6가지 제약조건이 존재하는데요, 로이 필딩은 이 6가지 제약조건들을 만족하면 WWW이 더욱 단순화되고 개선될 것이라 보았습니다.

 

그럼 REST에 어떤 제약조건들이 있는지 알아보러 가볼까요?

 

클라이언트 - 서버 구조(Client - Server)

REST의 첫번째 제약조건은 클라이언트 - 서버 구조입니다. 아마 웹 개념을 조금이라도 접하신 분들은 많이 들어보셨을 것 같습니다. 예상하시는대로 개념도 간단한데요, 클라이언트는 요청을 발생시키고, 서버는 요청에 응답해야 한다는 제약조건입니다.

 

이렇게 관심사의 분리를 적용하면 클라이언트는 UI의 이식성에만, 서버는 확장성에만 집중할 수 있게 됩니다. 예를 들어 볼까요?

클라이언트는 요청을 발생시키고, 서버는 단순히 응답만 하면 되기 때문에 각자의 책임이 명확합니다. 클라이언트가 안드로이드가 되든, IOS가 되든, 웹이 되든, API가 되든 간에 서버는 단순히 요청에 걸맞는 응답만 전해주면 되는거죠. 클라이언트 입장에서도 서버의 구현 세부사항에 대해 알지 못해도 요청만 전송하면 원하는 응답을 얻을 것이라는 기대를 할 수 있습니다. 즉, 클라이언트와 서버가 독립적인 진화가 가능해지는 것이죠.

 

 

무상태성(Stateless)

REST의 두번째 제약조건은 무상태성입니다. 이는 요청은 상태를 가지지 않아야 한다는 제약조건입니다. '상태를 가지지 않는다'는 말이 쉽게 와닿지는 않는 것 같습니다. 따라서 예시를 통해 이해해보겠습니다.

 

클라이언트와 서버가 통신을 하고 있다고 가정해봅시다. 클라이언트가 서버에게 처음 요청을 보낼 때, 다음과 같이 메세지를 보냅니다. 'ID는 테오이고 장바구니 정보를 줘!'

 

그러면 서버는 정상적으로 응답을 할 것입니다. 하지만 몇분 뒤, 클라이언트가 ID 정보 없이 장바구니 정보를 달라고 메세지를 보낸다면 서버는 '누구세요?'라고 응답을 합니다.

 

무상태성은 이처럼 서버가 클라이언트에 대한 상태를 가지지 않는다는 것을 의미합니다. 조금 더 쉽게 이야기하면, 서버는 요청을 보낸 클라이언트가 이전에 어떤 요청을 보냈는지 모른다는 것이죠. 그렇기 때문에 클라이언트가 보내는 각각의 요청은 필요한 모든 정보를 포함해야 합니다.

 

 

캐시 가능성(Cache)

REST의 세번째 제약조건은 캐시 가능성입니다. 서버는 자원에 대해서 캐시가 가능한지 아닌지를 명시해야 한다는 제약조건입니다. 마찬가지로 그림을 통해 이해해보겠습니다.

 

클라이언트가 장바구니 정보를 달라고 요청을 보냈다고 가정해보겠습니다. 그리고 서버는 정상 응답을 하는데, 이게 캐시 가능하다! 라고 마킹을 해줍니다. 그러면 동일한 요청을 일정 시간 내에 보내려고 할 때, 클라이언트는 요청을 생략하고 캐시된 자원을 사용할 수 있게 됩니다.

 

이처럼 캐시가 가능하다면 가능하다고 명시를 해주어, 클라이언트가 자원을 재사용할 수 있게 하라는 제약조건이 바로 세번째 제약조건인 캐시 가능성입니다. 

 

 

계층형 시스템(Layered System)

REST의 네번째 제약조건은 계층형 시스템입니다. 말 그대로, 시스템이 계층형으로 구성되어야 한다는 제약조건입니다. 시스템을 계층형으로 구성된다는게 잘 와닿지는 않는데, 마찬가지로 예시를 통해 알아보겠습니다.

 

위 그림에서 아래가 계층형 시스템을 구성한 예시입니다. 클라이언트 입장에서는 서버 하나에만 접근하는 것처럼 보이지만, 실제로는 계층형으로 구성된 시스템에 접근하게 되는거죠.

 

클라이언트가 A+B+C 라는 메세지를 보낸다고 한다면, 단일 서버 구조에서는 하나의 서버가 A+B+C 메세지를 모두 처리해야 하지만, 계층형 시스템으로 구성되어 있다면 인증서버는 A만, API서버는 B만, DB 서버는 C만 처리할 수 있게 됩니다. 즉, 복잡도를 획기적으로 낮춰주는거죠.

 

 

주문형 코드(Code-on-demand)

REST의 다섯번째 제약조건은 주문형 코드입니다. 이는 클라이언트가 필요에 의해 기능을 확장할 수 있도록 하는 제약조건을 의미합니다. 즉, 클라이언트가 주문을 하면 코드를 준다는 것입니다. 대표적인 주문형 코드를 적용한 예시로는 플러그인이 있습니다.

 

이런 구조는 클라이언트를 단순화하기에 효율적입니다. 기능이 필요할 때만 추가된다는 장점이 있죠. 하지만 이는 시스템 전반적으로 적용되었을 때는 오히려 비효율적일 수도 있습니다. 주문형 코드 제약조건을 만족하려면 서버는 클라이언트에게 제공할 기능들을 모두 가지고 있어야 하는데, 이는 오히려 서버의 부담을 크게 높이기 때문입니다. 그래서 이 주문형 코드 제약조건은 선택적인(optional) 제약조건입니다. 

 

 

균일한 인터페이스(Uniform Interface)

REST의 6번째 제약조건은 균일한 인터페이스입니다. 이 제약조건은 정말 중요하면서도 REST로 하여금 다른 아키텍처와 차별점을 두게 합니다. 

 

이는 클라이언트와 맞닿아 있는 부분(Http Request, Http Response)을 일반적이고 쉽게 설계하라는 제약조건입니다. 설명만 들으면 만족하기 쉬울 것 같지 않나요? 하지만 만족하기가 정~말 어렵습니다. 아마 대부분의 개발자분들은 이 제약조건을 온전히 만족하는 API를 본 적이 없을겁니다.

 

왜 그렇게 만족하기가 어려운지, 어떤 내용을 담고 있는지는 다음 포스팅에서 살펴보도록 하겠습니다.

 

 

---

요약

• REST라는 아키텍처는 6가지 제약조건을 가진다.
• optional한 주문형 코드 제약조건을 제외하고 나머지 제약조건을 모두 만족시켜야 REST를 만족하는 것이다.
• 하지만 균일한 인터페이스 제약조건의 경우 완전히 만족하기가 매우 어렵다.
• 왜 그런지는 다음 포스팅에서 같이 살펴보도록 하자.