항상 RESTful한 API를 개발해야지 하면서도
RESTful이 뭐냐고 물어보면 GET,POST....로 얼버무렸던 나....
나는 API 서버를 제대로 구현해 본 적이 있던가?
API의 주된 목적은 인터페이스 이다. 그렇다면 과연 인터페이스가 뭘까?
인터페이스는 두 개의 시스템, 대상, 조직, 또는 그 박의 대상들이 만나도 상호작용하는 지점이다.
그렇다면 우리가 흔하게 부르는 API 특히, 웹 API는 함수를 통해서 데이터를 입력하고, 또는 출력하는 피드백을 제공할 수 있어야 한다. 이러한 함수들은 애플리케이션끼리 정보를 검색, 전달하거나 특정한 작업을 유도할 수 있어야 한다.
요약
- 웹 API는 HTTP 프로토콜을 사용하여 소프트웨어를 재사용 가능한 블록으로 변화시켰다
API는 애플리케이션을 개발자하는 개발자들이 여러분의 서비스를 소비할 수 있게 해주는 인터페이스- 퍼블릭 API이든 프라이빗 API이든 어떤 API를 만들더라도 API 디자인을 고려해야 한다
- 좋은 API를 디자인하기 위해서는 인터페이스 뿐만 아닌 모든 컨텍스트를 고려해야 한다.
REST
REpresentational
State
Transfer
- 어떤 리소스의 특정 시점의 상태를 반영하고 있는 정보
처음으로 돌아가보자...
일단 Web이란 무엇인가?
어떻게 인터넷에서 정보를 공유하는 것인가?
A. 정보들을 하이퍼텍스트로 연결한다
- 표현방식 : HTML
- 식별자 : URI
- 전송방법 : HTTP
REST API는?
- REST 아키텍쳐 스타일을 따르는 API
그렇다면 REST는?
REST
분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
클라이언트는 원하는 자원과 그 표현을 요청하고 서버는 표현을 선택해 전송한다. 서버는 자원이 아닌 자원의 표현을 응답으로 보낸다.
REST를 구성하는 제약조건
- client-server 구조
- Stateless
- 웹 표준을 그대로 사용할 수 있어야 함
- 요청간의 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있음
- Cache
- Layered system
- 요청된 정보를 검색하는데 관련된 서버(보안, 로드 밸런싱 등)의 각 유형을 클라이언트가 볼 수 없는 계층화된 시스템
- Code-on-demand
- 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능
- Uniform interface
- 서버와 클라이언트가 각각 독립적으로 진화한다
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다
- Self-descriptive message : 메시지는 스스로 설명해야한다 즉, 메시지만 보고도 어떤 기능을 수행하는지 알아야 한다.
- hypermedia : 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 한다.
!! 여기서 HATEOAS를 짚고 넘어가자
HATEOAS(Hypermedia As the Engine Of Applacation State)란 무엇인가?
- 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다
link의 href를 통해 애플리케이션 상태를 이동할 수 있다.
따라서 이 모든 REST 제약조건을 모두 만족을 해야 RESTful API이다.
reference
개발 경험 저장소