REST, REST API, RESTful

 

REST는 Representational State Transfer의 약자로 네트워크상에서 존재하는 애플리케이션을 만들기위한 아키텍처 스타일을 뜻한다. REST에는 6가지 아키텍처 가이드라인이 있는데 개발자라면 이미 몸소 체득했을 것이다.

 

REST Guidelines

Uniform Interface

Resource 에 대한 요청을 통일되고 한정적으로 수행해야한다. 요청하는 Client 플랫폼에 종속되지 않고 사용할 수 있는 형태가 돼야함을 말한다.

 

Client - Server

유저의 인터페이스는 클라이언트에서 데이터와 관련된 것은 서버에서 처리해 관심사를 분리한다. 다른 말로 하면 클라이언트와 서버가 따로 독립적으로 개선될 수 있어야 한다.

 

Stateless

클라이언트와 서버는 요청을 완료 할 때 필요한 정보를 모두 제공해야한다. 다른 말로 표현하면 서버는 이전에 주고 받았던 정보를 이용해서 처리하는게 아니라 요청이 일어난 시점에 제공된 정보만을 이용해서라도 완료할 수 있어야 한다. 클라이언트의 컨텍스트는 서버에 저장되면 안되며 애플리케이션의 상태를 관리하는 것은 클라이언트 그 자체여야 한다.

 

Cacheable

응답이 캐싱될 수 있어야 한다. 캐싱은 클라이언트, 서버 상에서 일어날 수 있으며 성능 샹상에 도움이 된다. 

 

Layered System

계층화된 구조를 활용해서 각 컴포넌트의 행동을 제약하고 추상화 할 수 있다. 예를 들어 서버가 API용으로 한대, 스토리지용으로 한대, 인증용으로 한 대가 있다면 클라이언트는 어떤 서버에 요청을 보내고 있는지 구분할 수 없어야 한다.

 

Code on Demand(Optional)

클라이언트에 실행 가능한 코드를 보낼 수 있다. 하지만 이건 Optional하다. 

 

 

REST API, RESTful

REST API는 REST 아키텍처 가이드라인을 준수한 애플리케이션 프로그래밍 인터페이스를 말한다. RESTful 이란 REST를 REST 답게 잘 썼다는 비공식적인 용어다. Beaty + ful 을 합해진 Beatiful 에서 이름을 착안한 듯 싶다. 특별한 의미를 지니고 있는 용어인 것 같지만 간단히 둘다 REST 원칙을 준수한 코드를 칭하는 것으로 봐도 무방하다.

 

REST와 HTTP

REST를 HTTP는 엄연히 다른 개념이긴 한데 등장한지 20년이 지나며 개발자들 사이에선 두 용어를 혼합해서 사용하는 경향이 있다. HTTP는 GET, PUT, POST, DELETE 의 용도에 따른 사용법을 다룬다면 REST는 앞서 말한 디자인 원칙에 더 포커스를 둔다. 예로 서버상에서 어떤 데이터를 업데이트를 POST를 사용해서 했다면 PUT을 사용해야 한다는 HTTP 원칙과는 거리가 있지만 Uniform Interface를 제공해야 하는 REST 원칙에는 부합해 RESTful 하다고 말 할 수는 있다. 그런데 개인적으로 이 차이를 알고 있는 것보다는 고유한 원칙을 적재적소에 잘 사용하는 것이 중요하다고 생각한다.