여는말
요즘 개발자 채용 공고에서 REST API 개발 경험은 필수적인 요소로 자리잡은 것 같다. 하지만, REST란 무엇인가? 스스로 물어봤을 때 추상적인 개념들만 떠올랐고 제대로 공부해본 경험은 없는 것 같았다. 좋은 API 설계를 위해 REST를 더 공부해야함을 느꼈고 이번 기회에 구조화된 글로 나타내보려고 했다.
REST는 네트워크 아키텍처다
REST(Representational State Transfer)는 무엇일까? REST는 프로토콜이 아닌 아키텍처 스타일이다. REST 아키텍처는 ‘로이 필딩’의 박사 논문(https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm?utm_source=chatgpt.com)에서 처음 제시되었다.
위키피디아( https://ko.wikipedia.org/wiki/REST )는 REST를 아래와 같이 정의하고있다. ‘
REST(REpresentational State Transfer) 는 엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다.
RESTful의 정의
그렇다면, RESTful은 무엇일까? 엄밀히 말하면 로이 필딩의 논문에서 정의한 제약조건들을 충족한 서비스를 RESTful하다고 부를 수 있다. 하지만, 현대에는 RESTful 용어가 느슨하게 사용된다. 클라이언트는 HTTP 표준 메서드와 URL로 API에 데이터를 요청하고 서버는 일관된 인터페이스를 제공한다면 RESTful하다고 말할 수 있다.
RESTful의 정의에서 말한 제약조건은 위키피디아에서 말한 네트워크 아키텍쳐 원리와 동일하다.
REST의 6가지 제약조건
1. 클라이언트-서버 구조(Client-Server)
클라이언트와 서버를 나눠 관심사를 분리한다. 자원을 제공하는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트다. 클라이언트는 데이터 저장에 신경 쓰지 않는다. 서버는 사용자 인터페이스나 사용자 상태에 신경 쓰지 않는다. 결과적으로, 인터페이스가 변경되지 않는 한 클라이언트와 서버는 독립적으로 교체, 개발, 확장될 수 있다.
2. 무상태성 (Stateless)
REST의 핵심은 무상태이다. 무상태성은 요청을 처리하는 데 필요한 모든 상태(요청을 처리하기 위해 서버가 알아야 하는 정보)는 요청 자체에 포함되어야 한다. 무상태성은 이전 요청과 현재 요청이 관계가 없다. 과거와 상호작용하지 않는다.
요청을 처리하는 데 필요한 상태 정보는 URI, 쿼리 파라미터, 바디, 헤더에 담길 수 있다.
- URI는 리소스를 고유하게 식별하고, 본문은 리소스의 상태(또는 상태 변경)를 포함한다.
- 서버는 요청 간 세션 상태를 유지하지 않는다.
REST에서는 상태를 유지하지 않고 클라이언트가 요청마다 필요한 모든 상태를 포함시키므로 어떤 서버든 클라이언트의 요청을 처리할 수 있다. 여러 대의 서버로 구성된 시스템에서 로드 밸런서가 어떤 서버로 요청을 보내든 상관없으므로 확장성이 높다.
서버 구현이 단순해지며 특정 서버가 다운되더라도 다른 서버가 문제없이 요청을 처리할 수 있어 안정성이 높다. 요청에 필요한 모든 정보가 있으므로 요청의 의미를 파악할 수 있어 테스트, 디버깅에 용이하여 가시성이 높다.
무상태성의 단점, 트레이드 오프
- 여러 요청에 걸쳐 반복적으로 데이터를 전송하게 된다. 네트워크 오버헤드가 증가한다. ex) 인증 토큰
- 애플리케이션 상태가 클라이언트에 놓이게 되어 서버가 일관된 애플리케이션 동작을 제어하기 힘들다. 클라이언트의 버전이 달라질 수 있고 버전에 따라 다른 로직을 수행할 경우가 생길 수 있다.
3. 캐시(Cache)
네트워크 효율성을 개선하기 위해 클라이언트는 응답을 캐시할 수 있어야 한다. 응답은 응답 데이터가 캐시 가능한지 여부를 나타내야한다. 만약, 응답이 캐시 가능하다면 클라이언트는 캐시를 이용해 응답 데이터를 재사용할 수 있다. 클라이언트-서버 요청/응답 상호작용의 지연(latency)를 줄일 수 있다. 캐시는 주로 HTTP GET 메서드 요청에 사용한다.(GET은 멱등하고 리소스의 상태를 변경하지 않기 때문이다.)
그러나, 트레이드오프 역시 존재한다. 캐시에 오래된 데이터가 남아 있다면 서버로부터 얻을 수 있는 데이터와 다를 수 있어 신뢰성(reliablility)이 떨어질 수 있다.
4. 통합 인터페이스 (Uniform Interface)
4.a. 자원 식별 (Resource Identification)
리소스는 URI를 통해 식별한다. 모든 리소스는 고유한 URI를 가지며, 클라이언트는 URI를 통해 리소스에 접근한다.
4.b. 표현을 통한 리소스 조작 (Manipulation of Resources Through Representations)
클라이언트는 실제 리소스가 아닌, 리소스를 나타내는 JSON/XML 형식으로 된 표현을 통해 리소스를 조작한다. 서버는 표현을 받아 실제 리소스를 변경한다.
4.c. 자기 서술적 메시지 (Self-descriptive Messages)
메시지(요청/응답)는 메시지를 어떻게 처리할지 스스로 설명할 수 있어야한다. 응답은 캐시 가능한지 여부를 명시적으로 포함해야한다.
ex) Content-Type: application/json ⇒ 이 요청/응답의 본문은 JSON 형식이다.
4.d. HATEOAS (Hypermedia As The Engine Of Application State)
애플리케이션의 상태는 하이퍼미디어(링크)를 통해 전이된다. 서버로부터 받은 응답안에 클라이언트가 할 수 있는 다음 행동이 링크로 포함되어있는 걸 말한다.
ex) 게시글 상세 조회 요청시 응답 예시
{
"id": "1",
"title": "REST API 설명",
"content": "...",
"_links": {
"self": { "href": "/posts/1" },
"comments": { "href": "/posts/1/comments" },
"edit": { "href": "/posts/1", "method": "PUT" },
"delete": { "href": "/posts/1", "method": "DELETE" }
}
}5. 계층화 시스템(Layered System)
클라이언트는 자원을 요청할 때 어떤 서버와 통신하는지 알 수 없어야 한다. 클라이언트는 최종 서버에 연결된 것인지 중간 서버를 거친 것인지 알 수 없다. 중간 서버는 프록시, 로드 밸런서, CDN 등이 올 수 있다. 계층 시스템은 여러 계층을 거쳐서 통신하기 때문에 데이터 처리 과정에 오버헤드가 발생한다. 하지만 캐시 제약 조건을 지원하는 네트워크 시스템에서는 중개자에 공유 캐시를 두어 이 단점을 상쇄할 수 있다.
6. 주문형 코드(Code on Demand, Optional)
서버는 클라이언트에 코드를 전달하여 기능을 확장할 수 있다. 서버는 javascript 코드를 전달하고 클라이언트 측에서 스크립트를 실행할 수 있다. 이 제약조건은 의무가 아니며 선택적으로 적용할 수 있다.
REST를 통해 얻을 수 있는 것
이렇게 어려운 REST 제약조건을 잘 지켜 RESTful한 서버를 만들었다. 그렇다면 REST를 통해 어떤 이점을 누릴 수 있을까? 로이 핃딩의 논문에서는 다음과 같이 말하고 있다.
컴포넌트는 독립적으로 동작하며 인터페이스를 통해 다른 요소와 상호작용하는 단위이다.
- 컴포넌트 간 상호작용의 확장성(scalability)
- 인터페이스의 일반성(generality of interfaces)
- 컴포넌트의 독립적인 배포(independent deployment)
- 중개자(intermediary components)를 활용한 상호작용 지연(latency) 감소, 보안 강화(security enforcement), 레거시 시스템 캡슐화(encapsulation of legacy systems)
느낀점
제대로 공부하기 전엔 REST를 좋은 API 설계를 위한 원칙 정도로 알고 있었다. 하지만, REST 아키텍처의 논문을 기반으로 공부해보니 API 설계 뿐만이 아닌 네트워크 전반적인 설계 철학을 배울 수 있었다. 특히, 로이 필딩은 REST 뿐만이 아닌 HTTP 스펙도 개발했다고 한다. 그래서 개념적으로 HTTP와 REST의 연결되는 부분을 서로서로 더 잘 이해하게 된 것 같다. 다만, 엄밀히 말해 RESTful이라는 것은 위의 6가지(Code on Demand는 선택적) 제약조건을 지킨 것이다. HEATEOAS 제약조건을 처음 알았을 때 충격적이였다. 한번도 개발해본 경험이 없고 들은적도 없어 나에게 새로운 개발 패러다임이였다. 현대 빅테크 기업들의 서버들도 HATEOAS를 잘지키고 있는지 어떤식으로 개발하는지 궁금하다.
