REST API의 6가지 특징

웹 개발과 관련된 JD를 살펴보면, REST API 제작 경험을 요구하는 경우가 종종 있습니다. 서버가 직접 템플릿을 이용해서 필요한 데이터를 넣은 뒤 화면을 출력해주는 SSR(Server-side Rendering)과 반대된다고 말하기엔 무리가 있지만, 아무래도 사용자가 보는 화면을 누가 담당하느냐의 기준에서 차이가 나기에 서로 비교의 대상이 되는 것 같습니다.

간단하게 생각해서 SSR은 서버가 데이터를 직접 찾아 넣어준다면, REST API는 클라이언트와 서버 쪽이 분리되어 서버는 클라이언트가 필요해서 http 형식으로 요청한 내용을 json 같이 약속된 형태로만 전달하고, 이를 가지고 클라이언트는 별도로 작업을 하여 사용자에게 제공하게 됩니다.

RESTful API

사실 REST API를 찾아보면 RESTful API라고 명시하는 걸 많이 볼 수 있습니다. REST한 API라고 대충 번역해볼 수 있는데, 즉 REST라는 것이 어떤 특징을 나타낸다고 볼 수 있습니다.

REST는 REpresentational State Transfer의 줄임말입니다. 깊게 들어가면 설명할 것이 많겠지만, 단순하게 생각하자면 어떤 상징적인 상태를 전송한다고 볼 수 있습니다. 무엇의 상징적인 상태일까요? 바로 서버가 응답해줄 데이터입니다. 데이터라는 것은 사실 눈에 보이는 것이 아닐 수 있고, 컴퓨터의 저장된 형태를 우리는 우리가 이해할 수 있는 문자열로 치환해서 사용하고 있습니다. REST도 마찬가지로 이러한 데이터를 상징적인 형태, 그중에서도 JSON 같이 어느 쪽에서든 잘 해독하여 읽을 수 있는 것으로 변경하여 전송하는 것을 기반으로 하게 됩니다.

그렇다면 데이터를 주고 받는 어떠한 형식과 룰에 대한 이야기라는 건 이해가 가는데, 구체적으로 어떤 특징이 있어야 RESTful 하다고 부를 수 있을까요? 위키피디아의 REST API 페이지를 살펴보면 다음과 같은 6가지가 제시되어있습니다.

REST API 특징

Client-server architecture

영역을 클라이언트와 서버로 분리합니다. 유저 인터페이스와 데이터를 저장하는 두 가지의 문제를 분리하게 되면, 서버가 처리할 부분이 줄어들고 여러 플랫폼과 유저 인터페이스 형태로 확장하기가 쉬워집니다. 하나의 데이터를 요즘은 웹과 앱, 그리고 여러 기기에서 보여주어야 하기 때문에 이럴 때는 REST API의 사용이 빛을 보게 됩니다.

Statelessness

서버는 클라이언트에 대한 사전 정보나 클라이언트의 상태를 저장하지 않습니다. 다르게 말하면, 서비스의 클라이언트가 동작하는 과정에서 생기는 상태 변화에 대해 서버는 관여하지 않고 오로지 클라이언트단에서 감당하게 됩니다. 그렇기 때문에 요청은 반드시 서버가 해당 요청을 처리하기 위해 필요로 하는 모든 정보를 함께 전송해야 합니다. 즉, 상태가 없다, 라고 하는 것은 서버의 기준에서 하는 표현이라고 할 수 있겠습니다.

Cacheability

응답과 요청이 모두 캐싱 처리가 가능한지 아닌지 명시가 필요합니다. 캐싱이 가능한 데이터라면 클라이언트 차원에서 캐시에 저장해두고 이후에 같은 요청에 대해선 해당 데이터를 꺼내올 수 있게 됩니다.

Layered system

클라이언트 입장에서는 바로 끝단의 서버와 연결되어 있는지, 중간의 프록시나 로드 밸런서와 연결되어 작동하는지 알 수 없습니다. 보안을 위해 여러 겹의 서버나 통신이 있을 수 있고, 서버도 응답을 주기 다른 서버와 통신할 수도 있지만 클라이언트 입장에선 철저하게 분리되어 있기 때문에 직접적으로 바로 연결된 쪽과의 연결만 신경 써주면 됩니다.

Uniform Interface

REST의 특징을 갖는 서비스는 모두 편의를 위해 인터페이스에 일정한 제약을 갖고 있습니다. 어떠한 부분에 제약을 주는지는 다음과 같습니다.

Resource identification in requests

요청이 들어갈 때 필요한 정보(리소스)의 경우 URI 같은 걸 통해서 전달되고, 서버는 필요한 데이터를 JSON, XML과 같이 실제 데이터와는 다른 형태로 변경하여 전달합니다.

Resource manipulation through representations

클라이언트가 어떤 정보나 리소스의 상징이나 표현(representation)만 가지고 있더라도 이를 이용하여 실제 리소스의 상태를 변경시킬 수 있습니다.

Self-descriptive messages

각각의 메시지는 어떤 식으로 이 메시지를 해석하고 처리하면 되는지에 대한 정보를 담고 있습니다. 예를 들어, 어떤 파서를 사용해야 하는지는 media type에서 특정할 수 있다고 합니다.

Hypermedia as the engine of application state(HATEOAS)

최초 URI를 통해 REST 서비스에 접근했다면, 그 이후엔 서버가 제공하는 링크 등만을 활용하여 동적으로 리소스에 접근할 수 있어야 합니다. 클라이언트 차원에서 애플리케이션이나 서비스의 동작 방식, 구조에 대한 정보를 정적으로 지니고 있지 않아도 됩니다.

Code on demand(optional)

서버는 applet이나 스크립트 등을 전송하여 클라이언트의 기능을 확장하거나 변화(커스터마이즈)를 줄 수 있습니다.