RESTful
이 서비스는 RESTful하네요..
위의 REST Architecture를 구현한 서비스는 RESTful하다고 말한다.
Architecture Style은 "제약조건의 집합"이다.
시스템이 정확하게 RESTful하려면 다음 6가지 조건을 만족해야 한다.
- Uniform interface
일관된 인터페이스- URI, HTTP 메소드 사용 + RPC 미호출 등의 지정된 인터페이스를 준수
- Client-Server
클라이언트/서버- 클라이언트는 서버에 요청 메세지를 전송하고
- 서버는 요청에 대한 응답 메세지를 전송한다.
- Statelessness
상태 정보를 필요로 하지 않음- 이전의 상태를 저장하고 있지 않다
- 세션 등 이전 상황(문맥) 없이도 통신할 수 있다.
- Cacheable
캐시 가능- 서버의 응답 메세지는 캐싱(저장 후 재사용)될 수 있다.
- Layered System
계층화된 시스템- 계층별로 기능이 분리된다.
- 그러므로 중간 계층의 기능(로드 밸런싱, 서버 증설, 인증 시스템 도입 등)이 변경되어도 통신에 영향을 주지 않는다.
- code on demand (optional)
주문형 코드 (선택사항)- 손쉬운 데이터 처리를 위해 서버는 클라이언트에서 실행될 스크립트를 전송할 수 있다.
"Architecture"
REST는 아키텍처 스타일이다. 따라서 무조건적으로 해당 조건들을 만족해야되는 것은 아니다.
http만 잘 따라도 조건 충족이 쉽다. 하지만 첫 번째 조건인 uniform interface를 따르기가 좀 어렵다. 이러한 이유로 현재 REST API로 "불리우는 것"들 중에 정확하게 RESTful한 REST API는 없다.
uniform interface의 조건은 4가지가 있다. 위의 두 가지는 대부분 API가 쉽게 충족하지만, 아래 두 가지 조건을 대부분 API가 충족하지 못하고 있다.
self-descriptive messages
메세지 자기 자신을 설명할 수 있어야 한다.hypermedia as the engine of application state (HATEOAS)
애플리케이션의 상태 전이를 만족해야 한다.위의 두 가지 조건 달성이 의미하는 것
Self-descriptive -> 메세지만 가지고 해석 가능 -> 확장 가능한 커뮤니케이션
HATEOAS -> 애플리케이션 상태 전이 late binding
"독립적 진화 : 하위버전과 상호운용성"을 실현. 현존 가장 RESTful한 시스템은 Web이다.
- 웹페이지를 변경했다고 웹 브라우저를 업데이트할 필요 없다.
- 반대로 웹브라우저를 업데이트했다고 웹 페이지를 변경할 필요 또한 없다.
- HTTP 명세가 변경되어도 웹은 잘 동작한다.
- HTML 명세가 변경되어도 웹은 잘 동작한다.
위의 것들을 이뤄내기 위해 "하위버전과 상호운용성"을 끝까지 지켜내려고 노력하는 것이다.
무조건 완벽하게 REST API를 작성해야 해?
REST API는 REST 아키텍처 스타일을 따라야한다.
하지만 오늘날 스스로 REST API라 하는 API들이 대부분 아키텍처 스타일을 따르지않고있다.
제대로 REST API를 구현하지 못할거같으면 HTTP API라고 부르라고 한다.
왜 App에 구현된 REST API라고 불리는 API들은 위 두 가지 조건을 못 지킬까?
| - | REST API(Web) | HTTP API |
|---|---|---|
| protocol | HTTP | HTTP |
| communication | 사람-기계 | 기계-기계 |
| media type | HTML | JSON |
communication 상호 대상이 다르며, 이에 따라 media 타입이 다르기 때문이다.
HTML : text/html IANA 명세 html, body 명세 | 링크로 HATEOAS 만족
JSON : application/json 명세 | 하지만 id, title이 not-self discriptive | HATEOAS 불만족
충족 방법
Self-descriptive custom media type or profile link relation로 충족
HATEOAS HTTP 헤더나 본문에 링크 담아서 충족
