REST API란
- REST: REpresetational State Transfer, 로이 필딩(Roy Fielding)이 자신의 2000년 박사 학위 논문에 정의한 네트워크 소프트웨어 아키텍처
- 즉 REST한 방식으로 데이터를 상호교환 하도록 설계된 API를 의미
- HTTP를 잘 사용하기 위해, REST 아키텍쳐 스타일을 모두 준수한 API
HTTP: Hypertext Transfer Protocol, 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜
TCP/IP위에서 작동하며 어떤 종류의 데이터든지 전송 가능
REST API의 제약조건
- Client - Server
- Stateless
- Cache
- Uniform Interface
- Layered System
- Code-On-Demand (Optional)
가장 지키기 어려운 제약조건
1. Identification of resources
자원
- 이름을 지닐 수 있는 모든 정보
- 개념적인 대상
- ex) 문서, 이미지, 자원들의 집합, 실존하는 대상 등
URI(Uniform Resource Identifier)를 통해 자원을 식별할 수 있어야함. 자원(객체)에 대해 명시하고 그 객체를 식별할 수 있는 변하지 않는 식별자 {id}가 필요.
2. Manipulation of resources through representations
표현
HTTP 등의 메소드(표현) 을 통해 HTTP 메세지에 해당 리소스에 대해 어떤 조작을 하는지 명시.
--> REpresetational State Transfer(표현된 (자원의) 상태 전송)
3. Self-descriptive messages
메세지를 읽는 모든 주체(기계)들이, 메세지의 모든 요소는 메시지만 보고 그 의미를 파악할 수 있어야한다.
Self-descriptive messages 를 지키기 위한 방법
- 미디어 타입의 정의
- Link 헤더의 API 명세를 첨부
예시)
IP주소가 아니라 도메인명을 쓰는 이유
- 가상 호스트 문제, 하나의 IP주소에 복수의 도메인명이 존재할 수 있어서
다음 요청부터는 서버까지 찾아가는 것이 아니라 캐쉬된 컴포넌트에서 바로 정보를 제공받을 수 있음
4. HATEOAS
HATEOAS: Hypermedia as the engine of application state
- 하이퍼미디어를 통한 앱 상태를 변경할 수 있는 미디어를 제공해야함
- 현재 상태에서 어떤 페이지로 이동 가능한지 보여야한다는 것
위는 HATEOAS가 위배된 경우
REST API여야 하는가?
- Uniform interface 제약조건은 비효율적
- 애플리케이션에 필요한 정보가 아니라, 표준화된 방식으로 데이터 전달
- 상황에 따라 최선이 아닐 수 있음
따라서 HTTP API 같은 REST스타일의 API를 사용하든지, GraphQL API 같은 다른 API 표준을 사용할 수도 있음
RESTful API?
- 'REST API'를 제공하는 웹 서비스
- RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.
Reference