1. REST(Representational State Transfer)

: REST는 굉장히 포괄적인 개념이기 때문에, 여러가지 의미로 해석되지만, 사실 그 자체로 아키텍처인 것은 아니다. 하지만 대부분의 개발자들은 REST를 URI와 HTTP를 이용하여 객체화된 자원에 접근하도록 하는 웹서비스 설계로 이해하고 있다.

REST를 이해하기 위해서는 먼저 *ROA와 *URI를 짚어봐야한다.

ROA(Resource Oriented Architecture)

• Resource 중심의 네트워크 설계이다. 모든 서비스는 특정 Resource에 대한 접근이며, URI는 이러한 Resouce 들에 대한 유일한 접근점이다.

URI(Uniform Resource Identifier)

• 자원을 식별하기 위한 고유의 값이다. 웹서비스 환경에서 가장 보편적으로 쓰이는 형태는 URL(Uniform Resource Locator)이다.

ROA는 다음과 같은 특징을 가지고 있다.

• Addressablilty

  제공하는 모든 Resource는 URI로 표현이 가능하다.
  ex. 박명하란 사원에 대한 URI > Http://host:port/api/company/employees/myungha-park

• Connectedness

  Resource들이 서로 연관되어 있을 경우, URI 또한 서로 연관지어서 표현한다.
  ex. company/employees/myungha-park/name,
  company/employees/myungha-park/phone

• Statelessness

  Client의 상태를 Server에서 관리하지 않으며 모든 요청은 1회성이다.으로 설계한다. 따라서 매 요청마다 필요한 정보를 계속해서 전달해야한다.
  ex. 요청에 사용자 인증정보가 필요한 경우, 아래와 같이 할 수 있다. key = “접근이 허용된 사용자에게 발급되는 식별키”를 이용하여 API 설계시..
  company/employees/myungha-park/name?key=”xxsasaqweqw”
  company/employees/myungha-park/phone?key=”xxsasaqweqw”

• Homogeneous Interface

  HTTP에서 제공하는 Method를 이용하여, Resource의 모든 동작을 정의한다. 특정 Resource에 대한 접근은 오로지 하나의 URI로만 접근하며, 동작의 구분은 HTTP Method를 통해서 구분한다.

따라서 REST사상에 기반한 웹 서비스 아키텍처 설계란, 결국 웹 서비스에서 제공하는 모든 Resource들에 대한 접근점을 하나의 URI로 표현하고, 이를 HTTP란 수단을 통해서 전달하는 것을 의미한다. RESTFUL하다는 것은 REST사상(REST+ROA)의 기준/가이드를 충실히 준수하는 웹 아키텍처 설계라고 할 수 있겠다.

2. RESTFULL하게 설계하기

• Resource에 대한 URI는 동사보다는 명사를 이용하여 표현한다.

  URI는 Resource를 식별한다. 또한 Resource들간의 관계를 표현한다. 따라서 URI 작성시에는 동작에 해당하는 동사보다는 명사를 이용하여 표현하고, 동작은 HTTP Method를 사용하도록 한다.

URI로 표현되는 Resource 접근법

• Resource 조회
  HTTP GET : http://host:port/api/company/employees
• Resource 추가
  HTTP POST : http://host:port/api/company/employees
• Resource 수정
  HTTP PUT(PATCH) : http://host:port/api/company/employees
• Resource 삭제
  HTTP DELETE : http://host:port/api/company/employees

• Client와 Server는 서로 독립적이며, 하나의 Server가 다양한 Client에 모두 대응할 수 있다.

  Session과 같은 Client의 상태정보를 Server부터 독립하여, 서로 독립적인 관계를 유지하도록 한다. 따라서 매 요청은 연속적이지 않고, 서로 독립적이다. 매 요청이 독립적이기 때문에, 인증/권한에 대한 정보는 매번 Server로 요청되어야 한다. 대부분의 Open API의 경우, 다양한 방식의 인증정보를 제공하며, 매 요청시 해당정보를 Request에 포함하도록 하고 있다.

• Client가 원하는 데이터를 제공한다.

  각각의 Client들은 서로 다른 방식으로 Resource를 사용한다.(JSON, XML). 따라서 Servers 동일한 Resource에 대하여, Client에서 요청한 형태로 표현할 수 있어야한다. Server는 Request의 HTTP Header 를 통해서 Resource의 표현방식을 결정한다.
  ex. HTTP Header : Accept : Application/Json, HTTP Header를 이용할 경우, 하나의 URI로 다양한 형태의 Resource에 요청을 처리할 수 있게된다.

• 반응형 웹 환경에서도 동일한 URI를 제공한다.

  Client의 Device type 차이로 인해 반환되어야하는 Resource의 형태가 달라진다 하더라도(ex. www.naver.com, m.naver.com), Resource 자체가 동일한 경우, 하나의 URI로 처리한다. HTTP Header의 User-agent를 이용할 경우, 하나의 URI를 이용해도 반응형 웹의 처리가 가능하다.

• 다양한 언어를 동일한 URI로 제공한다.

  HTTP Header의 Accept-Language를 이용하여 다국어지원을 받을 수 있어야한다.

결론적으로 RESTFUL API는 ROA에 입각하여, HTTP를 충실히 활용한 웹 API이다.

모든 Resource를 표현하는 데 있어, 접근은 하나의 URI로만 가능하도록 엄격히 관리되어야 하며, Client 입장에서는 하나의 URI만으로 모든 표현이 가능하도록 쉽게 파악되어야 한다.

RESTFUL하게 작성된 API는 쉽게 이용이 가능하며, 확장이 용이하다. 또한 각 모듈별로 나뉘어서 재사용이 가능하다. 결국 유지/보수가 용이하며, 전체적인 아키텍처 설계에 비용절감의 효과가 있을 수 있겠다.

Ref :
Resource Oriented Architecture
REST란 무엇인가
RESTFUL이란?
RESTFUL이란 무엇인가
RESTFUL API란 무엇인가
REST 아키텍처를 훌륭하게 적용하기 위한 몇가지 디자인 팁
RESTFUL API를 설계하기 위한 디자인 팁