1. RESTful API
RESTful API¹ 서버를 만들려면 RESTful이 무엇인지 알아야 합니다. REST, 즉 Representational State Transfer를 직역하면 ‘표현식으로 데이터를 전송한다’는 의미입니다. REST란 로이 필딩(Roy Fielding)이 2000년에 소개한 웹 아키텍처 형식으로 REST 설계 원칙에 입각한 시스템을 RESTful API라고 부릅니다. REST는 여러 아키텍처 설계 방법을 합친 방식입니다. 여기서 그 모든 원칙을 설명하는 것은 책의 범위를 벗어나므로 간단히 소개하겠습니다. 더 자세한 사항은 구글에서 ‘웹 API 디자인’을 검색해보세요.
REST를 간단히 말하자면 URL과 메서드로 데이터와 동작을 표현하는 방식입니다. 예를 들어 웹 서버에서 학생 데이터를 가져오는 URL이 아래에 같다고 가정해보겠습니다.
이 URL이 하는 일이 정확히 무엇인지 이해하려면 먼저 getstudent.aspx가 무엇을 하는지 알아야 합니다. 이런 방식의 URL 요청은 자기 표현적²이지 못하기 때문에 범용성이 떨어집니다. 반면 다음과 같이 URL을 표현한다고 가정해보겠습니다.
URL과 메서드를 보면 이 요청이 3번 학생 데이터를 가져오는 요청이라는 것을 유추할 수 있습니다. 별도 외부 지식 없이 자기 표현적으로 요청 URL을 생성하고 환경에 구애받지 않고 똑같은 요청에 대해서 똑같은 결과를 보장한다면 범용적인 데이터 제공자(Data Provider)로서 동작할 수 있습니다.
HTTP 메서드
HTTP는 GET, POST, PUT, PATCH, DELETE 같은 메서드를 지원합니다. 이들 메서드를 사용해 데이터에 대한 동작을 정의합니다. 예를 들어보겠습니다.
위와 같이 URL과 메서드의 조합으로 데이터와 동작을 정의할 수 있습니다. 어떤 환경에서도 똑같이 메서드와 URL만 조합해서 요청을 만들 수 있기 때문에 범용적으로 사용할 수 있다는 장점이 있습니다.
이를 정리해보면 RESTful API는 다음과 같은 특징을 갖습니다.
- 자기 표현적인 URL: URL만으로도 어떤 데이터에 대한 요청인지 알 수 있습니다.
- 메서드로 행위 표현: 메서드로 데이터에 대한 행위를 표현합니다. URL과 메서드 조합으로 데이터에 대한 조작을 정의합니다.
- 서버/클라이언트 구조 : 서버는 데이터 제공자로 존재하고 클라이언트는 데이터 사용자로 동작합니다. 프론트와 백엔드로 분리하고 백엔드는 데이터만 제공하고 프론트에서 데이터를 처리하고 화면에 표시하는 역할을 합니다.
- 무상태(Stateless) : 서버는 클라이언트의 상태를 유지하지 않습니다. 서버가 상태를 보관할 필요가 없기 때문에 서버를 손쉽게 교체할 수 있어서 빠른 장애 대응이나 분산 처리에 유용합니다.
- 캐시 처리(Cacheable) : REST 구조로 서버가 단순해져서 더 쉽게 캐시 정책을 적용해서 성능을 개선할 수 있습니다.
2. RESTful API로의 발전
웹 서버가 RESTful API로 발전하면서 웹 서버에 어떤 변화가 생겼는지 살펴보겠습니다. 과거에는 웹 서버에서 완전한 HTML 문서를 만들어서 반환했습니다. 웹 브라우저가 하는 일은 웹 서버로 받아온 HTML 문서를 화면에 그려주는 일만 하면 됐습니다. 이런 방식을 서버 사이드 렌더링 방식이라고 합니다.
서버 사이드 렌더링 방식은 웹 브라우저에서 URL을 입력하면 웹 서버에 웹페이지를 요청하고 웹 서버는 전체 페이지 HTML을 만들어서 제공하는 방식입니다. 월드와이드웹에 대한 수요가 폭발적으로 증가함에 따라 서버 사이드 렌더링 방식의 문제점이 드러났습니다.
웹 서버 성능 문제
가장 큰 문제는 웹 서버로 성능 부하가 집중된다는 점입니다. 그래서 요청이 많아지면 웹 서버 성능이 저하되어 느리게 반응하는 문제가 생겼습니다. 사용자들의 빠른 반응에 대한 요구는 날이 갈수록 높아져만 갔습니다. 그러다 보니 다른 방식의 웹 서버가 필요해졌습니다.
다양한 환경에 대한 유연한 대응이 힘들다
스마트폰이 보급하면서 이제 컴퓨터 모니터만이 아니라 어디서나 웹페이지에 접근하는 시대가 되었습니다. 사용자 환경이 다양해지면서 다양한 크기의 디스플레이에서 웹페이지가 그려져야 했고, 웹 브라우저뿐 아니라 단말기나 다양한 디바이스에서 웹 요청이 증가되었습니다. 하지만 웹 서버에서 HTML 문서를 모두 만들어야 하는 상황에서는 이런 다양한 환경에 대한 유연한 대응이 힘들었습니다.
이때 AJAX(비동기 자바스크립트)와 같은 동적 웹 기술이 발전하면서 서버에서 모든 HTML 문서를 만드는 게 아닌 CDN(Content delivery network), 콘텐츠 전송 네트워크에서 빠르게 껍데기 문서만 제공하고 내용은 웹 서버에서 데이터를 읽어와서 채우는 클라이언트 렌더링 방식으로 변화되었습니다.
클라이언트인 웹 브라우저에서 URL이 입력되면 먼저 가까운 CDN으로부터 빠르게 템플릿 HTML 문서를 받아옵니다. 이 HTML 문서는 완성된 형태가 아닌 중간 중간 데이터가 비어 있는 형태로 빠르게 전송됩니다. CDN은 데이터를 채울 필요 없이 단순한 파일 서버 형태로 빠르게 사용자에게 일정한 템플릿 HTML 문서를 제공할 수 있습니다.
그러고 나서 웹 브라우저에서 AJAX와 같은 동적 웹 기술을 이용해 페이지를 완성시킬 데이터를 웹 서버로 요청하게 됩니다. 이때 웹 서버는 순수하게 데이터 제공자로서 동작하고 주로 JSON 포맷으로 데이터를 제공합니다. 이렇게 데이터를 받으면 클라이언트에서 HTML 문서를 그때그때 채워서 페이지를 완성하게 됩니다.
그래서 과거에는 웹페이지에 접속할 때 화면 전체가 한꺼번에 그려졌다면 요즘에는 첫 화면은 중간 중간 빈 형태로 빠르게 그려지고 점차 내용이 채워집니다.
클라이언트 렌더링 방식에서 웹 서버는 데이터 제공자로서 동작하기 때문에 범용적인 인터페이스가 필요해졌습니다. 그때 REST가 등장하면서 어떤 환경에서도 URL과 HTTP 메서드만으로 데이터와 동작을 표현하게 됨으로써 범용성을 가질 수 있게 되었습니다.
그 덕분에 네이버, 페이스북 같은 거대 웹 서비스에서 수많은 웹 서버가 범용적인 인터페이스를 이용해서 유기적으로 연결했습니다. 성능 부하를 여러 웹 서버로 분산해 더욱 빠르며, 일부 서버에 장애가 발생해도 전체 서비스는 중단되지 않습니다. 기능 변경 시에도 전체 웹 서버를 변경하지 않고 일부만 변경하면 되므로 유지보수가 더 쉬워졌습니다. 반면, 관리해야 하는 웹 서버 수가 급격히 늘어나서 사람이 일일이 관리할 수준을 벗어났습니다. 각종 자동 관리 툴이 탄생했고, 다양한 툴을 능숙하게 다룰 인력이 필요해졌습니다. 바로 DevOps라는 새로운 직종이 탄생하게 된 겁니다.
RESTful API 핵심 요약
- REST는 여러 웹 아키텍처를 합친 개념입니다.
- URL로 자기표현식으로 데이터를 나타냅니다.
- HTTP 메서드로 데이터 동작을 정의합니다.
- REST를 사용하면 어떤 서비스든지 일관된 표현식으로 표현할 수 있습니다.
- 서버에서 클라이언트 상태를 가지지 않음으로써 클라이언트와 독립적으로 서버가 존재할 수 있고 서버도 언제든지 교체해서 사용할 수 있습니다.
- RESTful API을 사용하면 서버가 범용적인 데이터 제공자로서 존재할 수 있어서 수많은 서비스 간 유기적인 연결이 가능합니다.
