REST API

REST(Representational State Transfer) 란?

애플리케이션 아키텍처 중의 하나로서, 네트워크 상에 존재하는 모든 자원(Resource)에 고유의 URI(Uniform Resource Identifier)를 부여하고, 자원의 상태를 다양한 표현의 응답으로 전송한다라는 의미이다.

 

좀 더 웹애플리케이션 관점에서 풀어서 말하자면, 웹애플리케이션에 존재하는 모든 자원에 고유한 URI를 부여하고,

클라이언트에서 HTTP METHOD(PUT / POST / DELETE / GET)를 통해 자원의 상태를 서버에 요청하고, 서버는 요청된 자원의 상태를 XML 또는 Json 형태의 데이터로 클라이언트에게 응답하는 것을 의미한다.  

 

현재는 PC웹브라우저뿐만 아니라 모바일 디바이스 등 다양한 클라이언트와 통신을 할 수 있어야 하기 때문에, 클라이언트와 서버간의 통신에 대한 정형화된 아키텍처가 필요하게 되었고, 그에 따라 REST라는 개념이 나오게 되었다.

•  

REST 구성 요소

1. 자원(Resource): URI

• 모든 자원에는 고유한 ID가 존재한다.
• 자원은 고유한 ID인 URI 로 나타낸다.
• Client는 URI를 이용해서 원하는 자원을 지정하고, 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.

2. 행위(Verb): HTTP Method

• HTTP 프로토콜의 Method를 사용한다.
• HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.

3. 표현(Representation of Resource)

• Client가 자원의 상태(정보)에 대한 조작 요청 시, Server는 응답을 보낸다.
• REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
• JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

REST 특징

• Client - Server 구조 : 클라이언트와 서버가 서로 독립적으로 분리돼 있어야 한다.

REST 서버는 API를 제공, 클라이언트는 사용자 인증 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로의 의존성이 줄어들게 된다.

 

• Stateless (무상태성) : 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않는다.

REST는 무상태성 성격을 가진다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않고, 이전에 클라이언트에서 요청한 정보를 저장하지 않기 때문에 API 서버는 그때 그때의 요청만 처리하면 된다. 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.

 

• Cacheable (캐시 가능) : 클라이언트는 서버의 응답을 Cache(임시저장) 할 수 있어야 한다.

HTTP라는 프로토콜을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서 HTTP가 가진 캐싱 기능이 적용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

 

• Layered System (계층형 구조) : 서버와 클라이언트 사이에 다양한 계층 형태로 구성 및 확장이 가능해야 한다.

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

 

• Uniform Interface (일관된 인터페이스) : 인터페이스의 일관성을 지키고, 아키텍처를 단순화시킨다.

HTTP 표준에만 따른다면, 안드로이드/IOS 플랫폼이든, 특정 언어나 기술에 종속되지 않고 모든 플랫폼에 사용할 수 있으며, URI로 지정한 리소스에 대한 조작이 가능한 아키텍처 스타일을 의미한다.

 

• Code on Demand (Optinal)

자바애플릿, 자바스크립트, 플래시 등 특정한 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 클라이언트로 전송하여 기능을 확장시킬 수 있다.

 

 

Uniform Interface (일관된 인터페이스) 규칙

1. 자원의 식별

개별 자원을 식별할 수 있어야 한다. 

 

2. 메시지를 통한 리소스의 조작

클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

 

3. 자기서술적 메시지

각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야할지에 대해 충분히 알려주지 못한다.

 

4. 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

클라이언트의 요청에 대한 데이터만 응답하는 것이 아니라, 관련된 리소스에 대한 Link 정보까지 같이 제공해줘야 한다. 현업에서는 이 부분은 잘 지켜지지 않고 있다.