Restful API
REST API의 설계 규칙을 올바르게 따르는 시스템을 말한다.
즉, REST API를 사용하였지만 RESTful 하지 못한 시스템일 수도 있는 것이다.
REST API란
REST (Representational State Transfer)
- 즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.
- 월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
- REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.
왜 필요한가, REST의 설계 목표
REST의 구성
-
자원 (URL)
=> 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다. -
행위 (Method)
=> Http Method를 사용한다.
=> HTTP프로토콜은 GET, POST, PUT, DELETE 과 같은 메서드를 제공. -
표현
=> 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다.
REST 특징
REST API 디자인을 정의한 Fielding 박사가 정한 6가지 기본 원칙이 있다고한다.
6가지 기본원칙
1. stateless
2. 클라이언트 서버구조
3. 균일한 인터페이스
4. 캐시가능
5. 계층화된 시스템
6. 주문형 코드
- 무상태성 (Stateless)
- 각 요청은 독립적이어야한다.
- REST는 HTTP의 특성을 활용하므로 stateless하다.
- 상태정보를 기억할 필요X, 들어온 요청에 대해 처리만해주면 되므로 구현이 쉽다.
- 클라이언트-서버 구조
클라이언트와 서버가 서로 독립적으로 작동할 수 있도록 분리되어 있어야 한다.
- 클라이언트: 유저와 관련된 처리
e.g. 인증, context(세션, 로그인 정보) 관리 - REST server : API 제공 및 비즈니스 로직 처리를 담당한다
서로간의 의존성이 줄어드는 장점이 있다.
-
균일한 인터페이스
통일성을 위한 REST에는 인터페이스 제약조건이 있다.
- 자원을 식별할 수 있어야한다.
=> URL 만으로 어떤 자원을 제어하려 했는지 알 수 있어야 함. - 행위는 명시적이어야 한다.
- 자원에 대한 표현
=> 클라이언트가 서버로부터 자원의 표현을 받았을때, 충분한 정보를 포함 해야한다. - 자기 설명 메시지
=> 데이터의 메타 정보만 가지고도 데이터 처리를 위한 정보를 얻을 수 있어야 한다. - 애플리케이션의 현재 상태에서 다음에 가능한 모든상태를 클라이언트가 알 수 있도록 하이퍼링크를 포함시켜야한다.
-
캐시 가능
REST API 응답은 캐싱이 가능해야 한다. 클라이언트는 응답을 캐시하여 나중에 동등한 응답에 대해 재사용 할 수 있음.
=> 애플리케이션의 성능향상 -
계층화된 시스템
클라이언트는 최종 서버와 직접 통신하는건지, 중간에 다른 계층이 있는건지 알 수 없어야 한다.
=> 각 계층의 구성 요소가 바로 다음 계층을 넘어 상호 작용할 수 없으므로 애플리케이션의 보안을 강화하는 데 도움이 된다.
=> 보안 및 안정성 향상에 좋음. -
주문형 코드
=> 이것은 선택적 제약조건
=> 클라이언트 코드나 애플릿을 다운로드하여 애플리케이션 내에서 사용할 수 있다.
