REST API

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 

 

REST API 의 특징

1) Client - Server 구조

클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써

클라이언트의 이식성과 서버의 규모확장성을 개선할 수 있습니다.

 

2) Stateless (무상태성)

클라이언트와 서버의 통신에는 상태가 없어야합니다. 모든 요청은 필요한 모든 정보를 담고 있어야합니다.

요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며,

상태를 저장할 필요가 없으므로 규모 확장성이 개선될 수 있습니다.

 

3) Cacheable (캐시 가능)

캐시가 가능해야합니다. 즉, 모든 서버 응답은 캐시가 가능한지 그렇지 아닌지 알 수 있어야합니다. 

효율, 규모 확장성, 사용자 입장에서의 성능이 개선됩니다.

 

4) Layered System(계층형 구조)

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고

PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

 

5) Code-on-demand (Optional)

자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.

 

-> 1)~5) 의 경우 HTTP 를 사용하면 대체로 잘 지켜짐. 6) Uniform Interface 가 관건. 

 

6) Uniform Interface(유니폼 인터페이스)

구성 요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야합니다.

인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호 작용의 가시성이 개선되며, 

구현과 서비스가 분리되므로 독립적인 진화가 가능해질 수 있습니다.

아래 네 가지 제약 조건이 존재.

• Resource identification in requests - Resource 가 URI 로 식별되어야 하다
• Resource manipulation through representations - 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
• Self-escriptive messages - 미디어 타입만 가지고도 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. IANA 에 등록된 명세들을 통해 확인 가능
• Hypermedia as the engine of application state (HATEOAS) - 애플리케이션의 상태는 Hyperlink 를 통해 전이되어야 한다. 

 

Web API / REST API 비교

* REST API 아키텍처 스타일을 완벽하게 구현하지 못할 경우 이를 Web API 라고 부름

	Web	REST API
Protocol	HTTP	HTTP
커뮤니케이션	사람-기계	기계-기계
Media Type	HTML	JSON
Hyperlink	됨 (a 태그 등)	정의되어있지 않음
Self-descriptive	됨 (HTML 명세)	불완전

 

참고)
https://www.boostcourse.org/web326/lecture/58986?isDesc=false

https://www.youtube.com/watch?v=RP_f5dMoHFc