-1차설명--------------------------------------------------------------------
HTTP 통신 프로토콜을 이용해서 요청과 응답메시지를 주고받는거에요.
자원에 대해 GET, POST 뿐만아니라 PUT, DELETE 요청이 있고,
HTTP가 원래 stateless 한 통신이기때문에 요청메시지 헤더에 토큰을 설정해서 인증을 받구요.
이 때 주고받는 데이터는 각 REST API 명세를 참고하시면되요.
HTTP 통신을 기반으로하기때문에 HTTP요청을 보낼 수 있는 모든 언어, 환경에서 사용가능하구요.
-2차설명---------------------------------------------------------------------
1.REST API (REpresentational State Transfer)
컴퓨터시스템간에 상호운영성을 제공하는 방법 중에 하나래요 (뭔말인지...)
2.REST가 어쩌다가 나온 계기인지?
시작은 WEB에서
Q.어떻게 인터넷에서 정보를 잘 공유할 것인가?
답변: 모든 정보들을 하이퍼텍스트로 연결을 하면 될 것이다.
표현 형식 : HTML (HTML이라는 형식으로 정보를 표현을 하고)
식별자 : URI (그 정보에 되한 식별자로 URI라는 것도 만들었고)
전송 방법 : HTTP (그리고 정보들을 전송하는 방법으로 HTTP라는 프로토콜까지 만들었다)
3.
Roy T. Fielding이라는 사람이
이미 94년에 HTTP/1.0 작업에 참여를 했다.
어떻게하면 웹을 망가트리지 않고 어떻게하면 HTTP를 징볼 시킬 수 있을 까?
그것의 해결 책으로 HTTP Object Model 이라는 것을 만든었다.
이것이 바로 4년 후(98년)에 이름이 REST라는 이름으로 발표를 하게 된다.
바로, 2년 후에 Roy T. Fielding이 이것을 박사 논문으로 발표를 하게 된다.
이것이, 바로 오늘 날 우리들이 알고 있는 REST라고 하는 것을 정의하는 그 논문이다.
4.
그런 한편, API가 만들어 지기 시작하는데,
인터넷 상에 API가 만들어 지기 시작 했다.
98년에 Microsoft에서 XML-RPC(1998)라고 원격으로 다른 시스템의 메소드를 호출할 수 있는 XML-RPC라는 프로토콜을 만듭니다.
이게 나중에 이름이 SOAP 으로 바뀝니다.
5.
이게 그냥 어떤 아이디로 오브젝트 하나를 가져오는 API의 요청 메세지가 이정도 불량이다.
flickr에서 만든 API이고 여러가지 형태로 만들었다 (SOAP, REST)
SOAP, REST 둘다 같은 일을 하는 API 인데, REST가 훨씬 짧다
차이점
| SOAP | REST |
| 복잡하다 | 단순하다 |
| 규칙 많음 | 규칙 적음 |
| 어렵다 | 쉽다 |
6.
다른 회사들도 이제 많이 REST API를 많이 쓴다.
7.
REST API는
REST 아키텍쳐 스타일을 따르는 API 이다.
8.
REST는
분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
*제약조건을 모두 지켜야 REST 따른다고 가능하다
9.
아키텍쳐 스타일은
제약조건의 집합
10.
REST 구성 스타일
- client-server
- stateless
- cache
- uniform interface
- layered system
- code-ondemand (optional) -> 서버에서 코드를 클라이언트에 보내서 실행 할 수 있어야 한다.
11.
- uniform interface (안에 뭐있는지)
11-1 은 Self-descriptive message 설명
11-2 은 Hypermedia As The Engine Of Application State 설명
11-1.
Self-descriptive message
해석 -> "메시지는 스스로를 설명해야한다"
예)
이런 메시지가 있어요. 그냥 루트를 어더오는 단순한 GET 메소드로 보내는 요청이죠!?
뭐가 빠져 있냐면 목적지가 빠져있다. 그래서 목적지 추가 해줌 (밑에 그림)
www.example.org 도메인으로 간다는 목적지가 빠져있었다.!!! (그래서 추가해줌)
그래서 이런 경우에 Self-descriptive에 부당 하지 않다라고 한다.
그리고 또 이런 메시지도 있을 수 있다.
응답 메시지 이다(밑에 그림)
200 OK로 응답을 하고
안에 JSON으로 된 본문이 있는데
이렇게 하면 또 Self-descriptive 하지 않다고 한다!!
왜냐하면
이걸을 해석할려고 하려면 클라이언트가 이 응답을 받고 해석을 해야하는데,
이게 어떤 문법으로 작성된건지 모르기 때문에 해석을 못해요!!
그래서 Self-descriptive 해줄려며는 "Content-Type: ~ " 헤더가 반드시 들어가야된다!! (밑에 그림)
"Content-Type :~" 헤더가 "application/json"이라고 되어 있으면!!!!
[ ] 이게 의미가 뭐고, { } 이게 의미가 뭐고, " " 감싸고있는 문자의 의미가 뭔지를
이젠 이해 할 수가 있게 되면서,
파씽이 가능해고, 문법을 해석 할 수 있게 되죠!
여기까지하면 Self-descriptive message이냐 는! 아니다!
이걸 해석 했다고 해도 op, path가 뭘 의미하는지를 알 수가 없다.
(이것만으로 부족하다!!)
그래서 이렇게 해야지 완전해진다! ( "-patch+json" 적어 주어야함 )
json-patch+json 이라는 미디어 타입으로 정의되어 있는 메시지이기 때문에
이거 대한 명세를 찾아가서 json-patch라는 명세가 있는데 그 명세를 찾아가서 이걸 이해 한다음에 이 메시지를 해석을 하면 그제서야 올바르게 메시지의 의미를 이해할 수 있게 됩니다!! (위에 그림)
이 처럼, Self-descriptive message를 하며는
이 메시지를 봤을 때, 메시지의 내용으로 온전히 해석이 다 가능 해야 한다!!
하지만!!!
오늘 날 REST API가 상당히 이것을 만족하고 있지 않다!
왜냐하면
미디어 타입을 보면 그냥 json이라고만 되어 있지,
이걸 어떻게 해석해야하는 가는
메시지만 보고서는 사실 알 수가 없다.
11-2.
Hypermedia As The Engine Of Application State (HATEOAS)는
애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.
예를 들어) 이런 웹사이트가 있다고 가정하면!!(밑에 그림)
웹사이트 루트에 접근하면 어떤 단순한 게시판 인데요!!
게시판 전체를 보면
링크가 있고
[글 목록 보기]링크를 누르며는
글 목록 보기를 위한 HTTP요청을 보내서,
글 목록을 가져오고
거기서 다시 [글쓰기] 링크가 밑에 있어요. 클릭하면
글쓰기 링크를 따라서
오른쪽으로 쭉 따라서
글쓰기 폼이 나오고
글쓰기 폼을 채워서
[글 저장] 링크를 클릭해서
글 저장 요청을 보내고
글이 저장되고 나며는
거기에 또 링크([생선된 글 보기])를 클릭해서
내가 저장한 글을 보고
글을 본다음에
[목록 보기]링크를 클릭해서
다시 목록으로 돌아가는……
요런 상태가, 이런게 애플리케이션 전이한다라는 거구요
이 상태 전이마다
해당 페이지에 있던 링크를 따라가면서
전이 했기 때문에
이건 Hypermedia As The Engine Of Application State(HATEOAS)가 된다.
말 그대로 하이퍼링크를 통한 전이가 된거죠!!!!!!!★★
----------------------------------------------------------------------------------------
"Content-Type: ~ "
HTML 에서 코드를 보며는 (밑에 그림)
HATEOAS를 만족하게 되는데요!
이렇게 a태그를 통해서 하이퍼링크가 나와있고
이 하이퍼링크를 통해서 그 다음 상태로 전이가 가능하기 때문에
HATEOAS가 만족이 되는거다
----------------------------------------------------------------------------------------
"Content-Type: ~ "
json으로 표현해도 만족할 수 있는 방법이 있는데요!!(밑에 그림)
링크("Link")라는 헤더가 있는데,
링크라는 헤더가
바로 메시지와 리소스가 연결되어 있는
하이퍼링크로 연결되어 있는
다른 리소스를 가리킬 수 있는
그런 기능을 제공해 주는 헤더 입니다.
여기서는 어느 한 게시물을 json으로 표현을 했는데요.
여기에 이전 게시물 URI가 /articles/1 이고 그 다음 URI가 /articles/3 이다라는 정보를 표현해 주었다.
또한, 이 정보는
링크 헤더가 이미 표준으로 문서가 나와 있기 때문에
이 메시지를 보는 사람이 온전히 해석을 해서
어떻게 링크가 되어있는지
이해하고 하이퍼링크를 타고 다른 상태로 전이가 가능합니다.
따라서 이것도 HATEOAS를 만족 한다.
----------------------------------------------------------------------------------------
11-3. uniform interface 왜 이런게 필요하냐?
독립적이라는 것은
서버가 코드(기능)가 바꼈어요(API 변경, 삭제, URI 변경 등등)
이런 변경이 있는데
클라이언트가 업데이트를 할 필요가 하나도 없는거다.
이것을 독립적 진화라고 말한다.
이게 바로 REST를 만들게 된 계기 이다.
아까 맨위에서 HTTP/1.0을 만들 때 Roy T. Fielding 고민 했던것,
내가 HTTP를 고치면 웹이 깨질 것 같은데, 어떻게 하면
이 문제를 해결 할 수 있을까?에 대한 고민에 대한 결과로 나온게
REST 이다!!!
그래서 REST가 목적하는 바는
독립적인 진화이고, 만족하기 위해서는 uniform interface가 반드시 만족해야 한다.
uniform interface가 만족 하지 않으면 REST라고 말 할 수가 없다.
그러면 실제 REST가 지켜지고 있는가 확인하는게 웹입니다.
웹은 매우 잘 만족하고 있다.
그런데
웹에서는 이렇지 않다, 앱에서 자주 생긴다. (밑에 그림)
(앱에 대한 댓글)
우리가 만든 모바일 앱 클라이언트하고 서버가 엄밀히 말하면 REST로 통신하고 있지 않다.
REST 아키텍쳐를 따르지 않는다고 할 수 있다.
12. REST가 웹의 독립적 진화에 도움을 주었나?
- HTTP에 지속적으로 영향을 주었가
- Host 헤더 추가
- 길이 제한을 다루는 방법이 명시(414 URI Too Long 등)
- URI에서 리소스의 정의가 추상적으로 변경됨: "식별하고자 하는 무언가"
- 기타 HTTP와 URI에 많은 영향을 줌
- HTTP/1.1 명세 최신판에서 REST에 대한 언급이 들어감
13. 그럼 REST는 성공했는가?
- REST는 웹의 독립적 진화를 위해 만들어졌다
- 웹은 독립적으로 진화하고 있다.
잘 성공 했음
14. 그런데 REST API는?
- REST API는 REST 아키텍쳐 스타일을 따라야한다.
- 오늘 날 스스로 REST API라고 하는 API들의 대부분이
REST 아키 텍쳐 스타일을 따르지 않는다.
15. REST API도 저 제약조건들을 다 지켜야 하는 건가?
다 지켜야 한다
16. 오늘 날은 (5번 바뀜)
차이점
| SOAP | REST |
| 복잡하다 | 단순하다 |
| 규칙 많음 | 규칙 적음 |
| 어렵다 |
17. 원격 API가 꼭 REST API여야 하는건가?
아니여도 상관 없지만,
시스템 전체를 통제할 수 있다고 생각하거나,
진화에 관심이 없다면,
REST에 대해 따지느라 시간을 낭비하지 마라.....
시스템 전체를 통제할 수 있다라고 하는 것은 무슨 말 이냐면,
우리가 회사에서 개발을 하는데,
제가 서버 개발자이고요,
다른 클라이언트 개발자가 있어요.
그러면 제가 저 클라이언트 개발자 통제가 가능하다.
18.
19.
20.
21.그런데 Self-descriptive와 HATEOAS가 독립적 진화에 어떻게 도움이 될까요?
쉽게 말해서: 링크를 마음대로 바꿀 수 있다는 애기 이다.