REST API

728x90

Rest API

(= Represenatational State Transfer)

문서, 이미지, 데이터 등의 컨텐츠와 기능을 네트워크를 통해서 활용할 수 있도록 제공되는 인터페이스이자 아키텍처 스타일
2000년도에 로디 필딩의 박사학위 논문에서 최초로 소개된 개념으로 HTTP처럼 규약이 있는 프로토콜은 아니다.
리소스를 중심으로 End Point(URL)를 생성하고, HTTP 메소드(GET, POST, PUT, DELETE)를 통해 동작을 수행한다.
- 자원 : 서버에 있는 문서, 이미지, 데이터
- End Point : 자원을 탐색하기 위한 URL로 모든 자원은 고유한 URL을 갖고 있다.
데이터의 포맷으로 JSON, XML을 사용한다.

(이 6원칙을 만족해야 Rest하다 라고 표현할 수 있다.)

Uniform Interface
자원에 대한 식별이 가능해야 한다.
HTTP 메서드를 통해서 자원을 조작해야 한다.
(ex. get / post 등)
Stateless
HTTP의 특징 중 하나로, REST는 HTTP 위에서 구현되기 때문에 REST 또한 무상태성을 가진다.
클라이언트의 상태가 서버에 저장되지 않고 각 요청에 대한 응답을 전송 받는 것으로 요청이 종료된다.
Cacheable
이 역시 REST는 HTTP 위에서 구현되기 때문에, HTTP 강력한 특징인 캐싱 기능을 활용할 수 있다.
다양한 캐싱 전략에 따라서 서버의 부하를 감소할 수 있다. (= 네트워크 리소스 및 인프라 리소스를 경감할 수 있다.)
Self-Descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 어떤 의도록 구성되어 있는지 직관적으로 파악할 수 있어야 한다.
(Request / Response / URL / Endpoint만 보고도)
즉, 쉽게 이해할 수 있는 구조여야 한다.
Client-Server
계층형구조

웹의 장점을 활용한 아키텍처
- 기존의 웹 환경인 TCP/IP 연결을 통해서 HTTP에서 쉽게 구현할 수 있다.
- 별도의 프로토콜 구현이 필요하지 않다.
- 특정 언어 및 기술에 종속되지 않는다.
  자바, 안드로이드 .. 등에 상관없이 동일한 REST API로 사용할 수 있다.
API EndPoint / 메시지만 보고도 해당 API 의도를 직관적으로 파악할 수 있다.

Overfetching (오버 패칭)
- 필요한 정보 값보다 더 많은 정보 값이 로딩 될 수 있다.
  (ex. 프로젝트에서 사용하고 싶은 정보는 영화에 대한 제목만 있으면 되는데 출연진, 작품 소개 등의 필요 없는 모든 정보를 다 받아야 한다.)
Underfetching (언더 패칭)
- 필요한 정보보다 부족한 정보 로딩으로 인해 추가 API 요청이 필요하다.
  (ex. 위의 상황과 대비되는 것으로 영화 전반 정보를 모두 요청하고 싶지만 TMDB API의 경우 정보들이 다른 API로 분산되어 있어서 추가 요청이 필요하다. -> 이에 부가적인 Request가 일어날 수 있다.)
Endpoint
- 서비스 규모가 커질수록 endpoint가 늘어나서 관리하기 어렵다.
- 서비스 pivot 및 업데이트로 기존 API Endpoint가 삭제되거나 변경될 경우 클라이언트 업데이트를 하지 않은 사용자에게 문제가 생길 수 있다.
  (-> 이러한 문제를 해결하기 위해 API 설계 시, /v1/user, /v2/user 형태로 API 버전을 관리한다.)

so-kyte