원 영상 링크: https://tv.naver.com/v/2292653
Representational State Trasfer
SOAP 등장
하지만 REST가 더 간단하고 쉬워 REST 승리
MS에서는 REST API 가이드나왔다.
하지만 REST를 만든 사람은 인정하지 않음.
왜일까? 사람들은 MS 가이드에서 나온 것을 좋은 REST API라고 하는데 REST API를 만든 개발자는 인정하지 않는다. 그 간극의 차이는 뭘까?
REST API
REST: 분산 하이퍼 미디어 시스템 웹같은것을위한 아키텍쳐 스타일
- 아키텍쳐 스타일: 제약조건의 집합, 이 제약조건을 다 지켜야 REST라고 할 수 있다.
이 중 Uniform interface의 제약 조건 중 아래 굵은 글씨의 두가지는 REST API에서 아예 지키지 않고 있다.
-
self-descriptive message: 메시지는 스스로 설명해야 한다. (12m 47~)
http 메세지만 보고 어떤 메시지인지 어떻게 해석해야하는지 부족하다.
-
HATEOAS: 애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
Link를 통해 이전 게시물의 정보를 제공하고 있음.
왜 Uniform interface 이 제약조건을 지켜야할까?
- 서버와 클라이언트가 각각 독립적으로 진화
- 서버의 기능이 변경되어도 클라이언트를 업데이트 할 필요가 없다.
근데 앱은 강제 업데이트 하는 경우가 있다.
웹에서는 웹사이트 바뀌었다고 동작을 하는 경우가 없다. 하지만 모바일 앱에서는 자주 그럴 수 있다.
=> 모바일은 REST 아키텍처로 동작하지 않는다.
HTML5, http/1.1 명세.. 등등 웹에서는 수많은 노력을 통해 하위호환성을 지키려고 노력함.
Rest가 웹의 독립적인 진화에 도움을 주었을까? YES
그런데 Rest API는? REST 아키텍쳐 스타일을 다르지 않음. 무조건 지켜야함.
하지만.. 이런 경우에는 지키지 않아도 된다.
현재 상태는 REST API가 아니지만 REST API라고 부른다 ㅎ
하지만 REST API 구현하고 REST API라고 부르는 법은 뭘까?
아래 비교 표를 보면 주로 http를 통해 데이터를 주고받을 때 json포맷을 사용한다.
self-desciptive와 HETEOAS가 독립적 진화에 어떻게 도움이 될까?
self-descriptive: 확장 가능한 커뮤니케이션
서버나 클라이언트가 변경하더라도 오고가는 메세지는 언제나 self-descriptive 하므로 언제나 해석이 가능하다.
HATEOAS: 애플리케이션 상태 전이의 late binding
어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이될 수 있는 상태가 결정된다. 쉽게 말해서 링크는 동적으로 변경될 수 있다.
방법1. mediatype
40분부터~
방법2 Profile
Hateoas
방법1 data로
방법2 http 헤더로
link, location
정리
