Rest는,
아키텍쳐 스타일
제약 조건의 집합 이것들을 모두 지켜야 rest를 따른다라고 말한다
Rest를 구성하는 스타일
client-server
stateless
cache
uniform interface
layered system
code-on-demand(optional)
"서버에서 코드를 클라이언트에 보내서 실행할수있어야한다"->이게 자바스크립트
Uniform Interface의 제약조건
- identification of resources(uri가 리소스로 식별되면 된다)
- manipulation of resources through representaitons(representaion 전송을 통해서 리소스를 조작해야한다) get,post,put , delete
모든 rest API들이 아래 2개는 못지키고 있다.
- self-descriptive messages
- hypermedia as the engine of application state(HATEOAS)
하이퍼링크를 통한 전이
Self-descriptive message
메시지는 스스로를 설명해야한다
GET/ HTTP/1.1
Host : www.example.org
목적지가 빠져있기 때문에 셀프 디스크립티브 하지못하다
HTTP/1.1 200 OK
[ { "op" : "remove", "path" : "/a/b/c" } ]
어떤 문법으로 작성된건지 몰라서 해석을 못한다
셀프 디스크립티브 하려면 Content-Type : application/json 이 반드시 들어가야함.
[ { " 이것들이 몬지 이해할수있게돼서 파싱이 가능해지고 문법을 해석할 수 있게된다.
여기까지 해도 셀프 디스크립티브는 아니다. op, path이게 뭔지를 알수없으므로.
Content-Type : application/json-patch+json 이라는 것까지 붙여줘야 스스로 설명한다고 한다.
메시지 내용으로 온전히 해석이 다 가능해야한다.
대부분의 미디어 타입을 보면 json이라고만 돼있다.
(HATEOAS)
애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다
예시)
HTTP/1.1 200 OK
Content-Type : text/html
<html>
<head></head>
<body><a href="/test">test</a></body>
</html>uniform interface 왜 필요한가?
-> 독립적 진화
서버와 클라가 각각 독립적으로 진화한다.(서버쪽 api든 데이터를 변경시켜도 클라가 그에 따라 변경시켜줘야 할필요가 없다)
서버의 기능이 변경되도 클라를 업데이트할 필요가 없다
REST를 만들게 된 계기: "How do I improve HTTP without breaking the web"
REST는 웹의 독립적 진화를 위해 만들어졌다.
웹은 독립적으로 진화하고 있다.
그런데 REST API는?
REST API는 REST 아키텍쳐 스타일을 따라야한다
오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
오늘날의 REST API는 REST API가 아니지만 REST API라고 부른다
이걸 만든사람이 그래서 말한다 " 제발 제약조건을 따르던지 아니면 다른 단어를 써줘.."
일단 왜 API는 REST가 잘 안되나?
일반적인 웹과 비교를 해보자.
JSON도 self-descriptive하게 만들기위하여..
방법1. Media type
1. 미디어 타입을 하나 정의한다.
2. 미디어 타입 문서를 작성한다. 이 문서에 "id"가 뭐고 "title"이 뭔지 의미를 정의한다.
3. IANA에 미디어 타입을 등록한다. 이 때 만든 문서를 미디어 타입의 명세로 등록한다.
*) IANA 모든 미디어 타입이 등록돼있는 사이트
4. 이제 이 메시지를 보는 사람은 명세를 찾아갈 수 있으므로 이 메시지의 의미를 온전히 해석할 수 있다.
단점, 매번 media type을 정의해야한다
Media type 등록은 필수인가? NO!
회사내의 사람들이 모두 알고 있다, 돌아가는 시스템을 모두 알고있다. 그럼 굳이 IANA에 등록할 필욘없다.
하지만 등록된다면 누구든지 쉽게 사용할 수 있게되고,
이름 충돌 피할수있고.
정리
- 오늘날 대부분의 REST API는 사실 REST를 따르지 않고있다.
- REST의 제약조건 중 특히, Self-descriptitve와 HATEOAS를 잘 만족 못한다.
- REST는 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것이다.
- REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정하여야 한다.
- REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야한다.
-- Self-descriptive는 custom media type이나 profile link relation등으로 만족시킬수있다.
-- HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족 시킬 수있다. - REST를 따르지 않겠다면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야할 것이다.
-- HTTP API라고 부를수도 있고
-- 그냥 이대로 REST API라고 부를 수도 있다.
==================
REST API
Representaional State Transfer(자원의 표현에 의한 상태 전달)
프론트에서 서버에 데이터를 요청할 때 REST API가 사용된다.
그 요청 모습 자체만으로 어떤 의미가 담겨있는지 알수있게해야한다.
RESTful하게 만든 API는 요청을 보내는 주소만으로도 대략 이게 뭘하는 요청인지 파악가능해야함
http://(도메인)/classes/2/students?sex=male
http://(도메인)/classes/2/students?page=2&count=10
위의것들을 URI라고한다.
면접) URI와 URL의 차이를 설명해봐라
URI: 자원을 구조와 함꼐 나타냄
서버에 REST API로 요청을 보낼떄는 HTTP 규약에 따라 신호를 전송함
HyperText Transfer Protocal
GET PUT POST DELETE
GET DELETE 보다 POST PUT PATDCH는 body란게 있어서 비교적 더 안전하게 감춰서 보낼 수 있다.
PUT PATCH 차이
PUT은 전부 바꿀때
PATCH는 일부 바꿀때
uri는 동사가 아닌 명사들로 이뤄져야한다는 규칙.
정리, REST API란, HTTP 요청을 보낼때 어떤 uri에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속.
