RESTful API
2020년 10월 27일, 22:55
REST (REpresentational State Transfer)
자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것.
웹 에서의 RESTful은
HTTP URI를 통해 자원을 명시하고, HTTP 메소드를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것.
REST 6가지 원칙
- Server-Client(서버 - 클라이언트 구조)
- 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
- 서로 간 의존성이 줄어든다.
- Stateless(무상태)
- HTTP 프로토콜은 Stateless Protocol
- Client의 context를 Server에 저장하지 않는다. → 구현이 단순해짐.
- Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
- 각 API 서버는 Client의 요청만을 단순 처리
- 이전 요청이 다음 요청 처리에 연관되어서는 안됨.
- Cacheable(캐시 처리 가능)
- HTTP 프로토콜 표준에서 사용하는 Last-Modified, E-tag를 이용
- 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구
- Layered System(계층화)
- Client는 REST API Server만 호출
- REST Server는 다중 계층으로 구성될 수 있음.
- API Server는 순수 비즈니스 로직을 수행하고 그 앞에서 보안, 로드밸런싱, 암호화 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있음.
- Proxy, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
- Code on demand(optional)
- Server로부터 스크립트를 받아서 Client에서 실행
- 반드시 충족할 필요는 없음.
- Uniform Interface(인터페이스 일관성)
- URI로 지정한 Resource에 대한 조작이 통일되고 한정적인 인터페이스로 수행.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다
- 특정 언어나 기술에 종속 X
RESTful API
- 리소스와 행위를 명시적이고 직관적으로 분리
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 함.
- 행위는 HTTP Method로 표현(GET,POST,PUT,PATCH)
- Message는 Header와 Body를 명확하게 분리해서 사용
- 내용은 Body
- 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등은 header에 담는다.
- API 버전을 관리한다.
- 환경은 항상 변하기 때문에 API의 signature가 변경될 수도 있음에 유의.
- 특정 API를 변경할 때는 반드시 하위호환성을 보장
- 서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.
- form-date 형식 또는 json 형식으로 둘 다 같이 주고 받는다.
장점
- Open API를 제공하기 쉽다
- 멀티플랫폼 지원 및 연동이 용이
- 원하는 타입으로 데이터를 주고 받을 수 있다.
- 기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.
단점
- 분산환경에 취약
- HTTP 통신 모델에 대해서만 지원
참고
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html