REST API에 대해 알아보자
REST?
REST는 Representational State Transfer의 약자로, 하나의 소프트웨어 아키텍처 형식이라고 볼 수 있다.
말이 조금 어려울 수 있는데, “자원을 특정 표현 또는 이름으로써 구분하여, 해당 자원의 상태 및 정보를 주고 받는 구조”을 의미한다고 이해하면 된다. 즉, 특정 규칙에 따라 이름을 지어서 자원의 상태를 구분짓는 것이다.
하지만… 글만 읽어선 여전히 REST의 개념이 모호하고 이해가 되지 않을 것이다. 따라서 REST의 구성요소와 핵심개념, 형태, REST의 특징 등을 하나 하나 짚어가며 학습해보도록 하자.
REST의 구성요소
우선, REST의 주요 구성 요소는 “자원, 행위, 표현”으로 이루어진다.
- 자원(Resource) : URI
- 행위(Verb) : HTTP 메소드 (GET, POST, PUT, DELETE)
- 표현(Representations)
자원과 행위는 우리가 개발을 하며 자주 접해봤던 개념들이라 이해하는 데 어렵지는 않을 것이다. 하지만 여기서 “표현”은 무엇을 의미하는걸까?
여기서 자원의 “표현”은 자원(정보)이 JSON, XML, TEXT, RSS 등으로 표현됨을 뜻한다. 즉, 데이터가 특정 형태로 정리 및 정제되어 우리에게 보여지는 형태를 설명하는 개념이 “자원의 표현”이라고 이해하면 된다.
REST의 특징 (6가지)
사실 REST를 공부하며 이 부분이 가장 이해가 안가고 어려웠다…
최대한 이해하기 쉽게 설명해보도록 하겠다 😇
우선 REST의 대표적인 특징 6개는 아래 사진과 같다.
무상태성 (Stateless) 🥹
HTTP는 무상태성을 띄는 프로토콜, REST는 무상태성을 띄는 ‘설계 구조’다.
여기서 무상태성이란, 서버와 클라이언트의 통신 사이에 상태 및 정보의 저장이 이루어지지 않는 것을 의미한다. 즉, 서버와 클라이언트 모두 “요청”을 통해서만 정보를 주고받는 것이다. 좀 더 자세히 설명하면, 서버는 세션정보, 쿠키, 인증정보 등을 따로 저장하지 않는다.
이는 곧 서버가 요청을 이행하는 데에 필요한 모든 정보가 요청에 담겨있어야 함을 의미한다. 서버는 어떠한 요청에 담긴 정보도 저장하지 않고 “응답”만을 이행하기 때문이다. 이에 따라 모든 요청과 응답은 독립적이며, 같은 요청에 대해서는 항상 같은 결과가 반환될 수밖에 없다.
이러한 무상태성을 통해 서버의 메모리 효율성이 제고될 수 있고, 그로 인해 서버의 부하가 줄어들 수 있다는 장점을 취할 수 있다. 심지어 응답결과가 일관될 수 있다는 안정성 또한 기대할 수 있을 것이다. 하지만 반대로, 무상태성 하에서 서버는 어떠한 정보도 저장하지 않기 때문에, 매 요청마다 모든 정보를 다 꼼꼼히 담아서 보내줘야 한다는 까다로움 또한 존재한다.
유니폼 인터페이스 (Uniform)
이 부분은 그리 어렵지 않은 부분이기에 간단하게 설명하고 넘어가도록 하겠다.
유니폼 인터페이스는 GET, POST, PUT, DELETE라는 HTTP 메소드를 통해 URI에 통일성 있고 한정된 방식으로 요청을 보내는 아키텍처 스타일이다. 즉, HTTP 메소드만을 통해서 URI로 지정한 리소스에 접근할 수 있는 일관된 통신방식을 유니폼 인터페이스라고 하는 것이다.
캐시 가능 (Cacheable)
REST는 HTTP 프로토콜을 그대로 따르기 때문에, 캐싱 기능을 그대로 적용할 수 있다는 장점을 갖는다.
HTTP 프로토콜 표준에서 사용되는 Last-Modified 태그나 E-Tag를 활용하면 캐싱을 똑같이 구현할 수 있다. 하지만 필자는 여기서 조금 의아함이 들었었다.
분명히 REST는 무상태성을 띈다고 했는데 캐싱이 어떻게 된다는거지..?
여기서 주의해야 할 점은, 캐싱은 서버에서 처리하는 것이 아니라 브라우저에서 처리된다는 것이다. 즉, 브라우저 내에 존재하는 저장소에 캐싱을 하기 때문에, 이는 무상태성을 저해하는 개념이 절대 아니다!
자체 표현 구조 (Self-Descriptiveness)
한 줄로도 설명이 가능한 부분이다.
사람이 REST API 메시지만 봐도 이게 무슨 요청을 하는 것인지 직관적으로 쉽게 이해할 수 있도록 하는 특징을 자체 표현 구조라고 한다 🙂
클라이언트 - 서버 구조
무상태성과 연결되는 개념이다.
무상태성에서 설명했듯, REST 구조에서 서버와 클라언트의 역할은 독립적이고 각자 맡은 역할이 명확하다. 이에 따라 우리는 서버와 클라이언트 사이의 의존성을 줄이며 안정성을 기대할 수 있게된다.
계층형 구조
클라이언트가 요청을 보내는 것은 API 서버 하나지만, API 서버 자체는 다중화된 계층으로 구성될 수 있음을 의미하는 개념이다.
즉, 클라이언트는 단순히 API 서버에만 요청을 보내는 것이지만, 요청을 받는 REST 서버는 로드 밸런싱, 암호화, 유저 인증 등의 계층을 두며 더 다양하고 넓은 기능의 활용을 기대할 수 있는 것이다.
그래서 핵심이 뭔가요..?
뭐 이제 대충 REST에 대한 개괄적인 개념은 잡았으니, 조금 더 간단명료하게 REST를 정리해보도록 하자.
REST란, HTTP URI를 통해 자원을 가독성 좋게 명시하고, HTTP 메소드(GET, POST, PUT, DELETE)를 통해 해당 자원(URI)에 대한 CRUD 오퍼레이션을 적용하는 것이다.
REST의 장점 😇
- HTTP의 인프라를 그대로 사용하기에, 따로 인프라를 구축하는 수고를 하지 않아도 된다.
- HTTP 표준 프로토콜을 따르는 플랫폼에서 모두 사용 가능하다는 범용성 측면의 장점을 갖는다.
- 요청의 의미를 파악하기 굉장히 쉽다.
- 서버와 클라이언트의 역할이 명확하게 분리되어 있다.
REST의 단점 👿
- 명확한 표준(약속)이 규정되어있지 않다.
- 사용 가능한 메소드가 4개로 한정적이다.
- 구형 브라우저에 대한 호환성이 낮다.
REST API
REST API는 뭐..
”REST의 구조를 잘 따르는 API를 의미한다” ^^
뜻은 굉장히 쉽지만, REST API를 설계할 때에는 반드시 주의해야할 점이 몇 가지 존재한다.
물론 위에서 REST에는 명확한 표준 또는 약속이 규정되어 있지 않다고는 했지만, 그래도 어느정도 지켜야 하는 최소한의 표준은 존재한다!
URI에는 명사만을 사용한다.
대문자 사용을 최대한 지양한다.
언더바(_)를 사용하지 않고, 하이픈(-)을 사용한다.
파일 확장자를 포함하지 않는다.
마지막에 슬래시(’/’)를 포함시키지 않는다.
URI에 HTTP 메소드가 들어가면 안된다.
Restful?
위의 REST API 설계 원칙을 잘 따르고, REST 구조의 원리를 잘 준수하고 있는 서비스는 RESTful하다고 표현할 수 있다.
우리는 RESTful한 API를 통해 요청과 통신 등을 쉽고 좀 더 명확하게 이해할 수 있다 🙂
참조 자료
What is REST - REST API Tutorial
REST API에 대해 알아보자