REST(ful) API는 무엇인가?

API(Application Programming Interface)

• 응용 프로그램에서 다른 응용 프로그램을 제어할 수 있게 만든 인터페이스
• 다른 응용 프로그램의 로직을 몰라도 제공받은 API를 사용해서 정의된 기능들을 쉽게 쓸 수 있다.
• Interface: 어떤 장치(or 소프트웨어)간 정보를 교환하기 위한 수단/방법

API 이해를 위한 예시

응용 프로그램들의 관계를 간단한 예시로 설명하자면,

 

1. 손님이 식당에서 음식을 먹기 위해서는 주방장에게 주문을 해야한다.

2. 손님은 메뉴판을 통해 식당에서 제공하는 음식을 알고 주문할 수 있다.

(주방장이 식당에서 내어줄 수 있는 요리는 정해져 있기 때문에 손님은 메뉴판의 음식만 주문해야 한다.)

3. 주방장은 들어온 주문대로 손님에게 음식을 요리해준다.

(손님은 주방에서 무슨 일이 일어나는지 관심가질 필요가 없다.)

 

대충 이런식으로 진행된다.

=====================================================

예시를 응용 프로그램1, 2를 대입해서 다시 이야기 해보자면,

 

1. 응용 프로그램1은 필요한 리소스, 데이터 등을 얻기 위해 응용 프로그램2에게 request를 보내야 한다.

2. 응용 프로그램1은 응용 프로그램2가 제공하는 API를 통해 받을 수 있는 리소스를 알고 제공받을 수 있다.

3. 응용 프로그램2는 API를 통해 들어온 request 대로 응용 프로그램 2에게 리소스를 제공한다.

(응용 프로그램1은 응용 프로그램2가 어떤 로직으로 짜여 있는지 알 필요 없다.)

 

요렇게 된다!

 

 

REST(REpresentational State Transfer)

• 직역으로는 "자원 상태 전달"
• 웹에서 사용되는 리소스를 이름(HTTP URI)으로 구분해서 request와 response를 정의하는 방식
• 서버와 클라이언트의 통신 방식(규약 보다는 아키텍처에 가까운 느낌)
• URI를 통해 리소스를 명시하고, HTTP Method를 통해 자원 교환

 

REST의 특징

1. Server-Client 구조

• 리소스와 API를 제공하는 쪽 - 서버
• 리소스를 요청하는 쪽 - 클라이언트
• 각각의 역할이 확실하게 구분되어(각각의 자원을 따로 관) 서로간의 의존성이 줄어듦

 

2. Stateless(무상태성)

• 클라이언트의 상태를 서버가 따로 저장/관리 하지 않음
  => 이전의 요청과 다음의 요청이 완전히 별개의 것으로 인식

 

3. Uniform(유니폼 인터페이스)

• 인터페이스 일관성
• URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하게 해야 함
  => HTTP 프로토콜을 따르는 모든 플랫폼에서 사용 가능하게끔 설계

 

4. Layered System(계층형 구조)

• 서버는 다중 계층으로 구성될 수 있음
  => 순수 비지니스 로직을 담당하는 API 서버의 앞단에 로드 밸런싱, 보안 요소 등의 역할을 하는 계층을 추가해서 구조상 유연성을 줄 수 있음
• 클라이언트는 서버의 구성과 상관없이 REST API 서버로 요청
  => 서버의 구조에 변경이 있어도 클라이언트는 영향을 받지 않는다는 것

 

5. Cacheable(캐시 가능)

• HTTP를 그대로 사용하기 때문에 웹에서 사용하는 캐시 기능을 그대로 활용 가능
• 똑같은 요청이라면 별도의 로직을 재실행하지 않고 동일한 결과 제공

 

6. Self-Descriptiveness(자체 표현 구조)

• REST API만 보고도 쉽게 이해할 수 있는 표현 구조로 되어있음

 

7. Code on Demand(Optional)

• 클라이언트가 리소스에 대한 표현을 응답으로 받고 처리해야 하는데, 어떻게 처리해야 할지에 대한 코드를 서버가 제공해주는 것
  => 서버가 클라이언트로 코드(or 스크립트)를 전달하여 클라이언트의 기능을 확장
• JavaScript 영역에서 많이 사용되는 개념

 

REST의 장점

• HTTP 프로토콜을 사용하는 모든 플랫폼에서 호환 가능
• 서버와 클라이언트의 역활 명확하게 분리 가능
• 서비스의 설계 부분에서 생길 수 있는 문제 최소화 가능 - HTTP로만 통신하기 때문

 

 

REST API

• REST 아키텍처를 따르는 어플리케이션 프로그래밍 인터페이스
• REST 아키텍처를 구현하는 웹 서비스를 RESTful 하다고 표현한다.

 

REST API 설계 규칙

• 웹 기반의 REST API를 설계할 경우, URI를 통해 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method로 표현한다.
• 행위가 URI에 포함되어서는 안된다.

   ex) 

      GET /questions/show/1 (x)

      GET /questions/1          (o)

 

• 슬래시 구분자(/)는 계층 관계를 표현하기 위해 사용하고 URI의 마지막에는 사용되지 않는다.

   ex)

      localhost:8080/animals/dogs/ (x)

      localhost:8080/animals/dogs (o)

• URI는 소문자로 작성한다.
• underscore(_, 밑)은 사용하지 않고, 필요한 경우 hypen(-, 붙임)을 사용한다.
• URI에 파일 확장자를 포함시키지 않는다.