REST API 란 ??
1. REST API 목적??
- REST API란 핵심 컨텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스입니다.
- REST는 REpresentational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다.
2. REST API 정의?
- REST 아키텍쳐 스타일을 따르는 API
- REST는 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일
* 아키텍쳐 스타일 : 제약 조건의 집합
3. REST 아키텍쳐를 구성하는 스타일?
- REST 아키텍쳐는 5가지의 규격을 엄격히 만족해야 한다.
1) client-server
- client - server 구조를 이루어야한다.
- 일관적인 인터페이스로 분리되어야 한다
2) stateless
- 상태 유지하지 않음
- 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
- 데이터를 주고 받는 것으로 끝나야 한다.
- 세션과 같은 컨텍스트 정보를 신경쓸 필요가 없어 구현이 단순해진다.
3) cache
- WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
4) layered system
- 계층 형 시스템 구조가 되어야한다.
- 서버는 클라이언트가 모르게 API 서버에 여러 계층을 추가하여 유연한 구조로 개발될 수 있다.
Ex) 서버에서 proxy나 gateway, 로드 밸런싱, 암호화 등의 기능들을 사용해도 client가 몰라야 한다.
5) code-on-demand (optional)
- 서버에서 코드를 클라이언트로 보내서 실행 할수 있어야 한다.(즉, javascript를 위미한다)
6) uniform interface ( 가장 지켜지기 여려운 부분 그러나 이걸 만족해야 REST API다)
- 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가
독립적으로 개선될 수 있도록 해준다..
- uniform interface를 만족시키는 4가지 조건
1) identification of resources
> Resource가 URI 로 식별되면 된다
2) manipulation of resources through representations
> representations 전송을 통해서 resources를 조작해야한다.
> representations이란 HTTP 메소드의 PUT, GET, DELTE 등을 말한다.
3) self-descriptive messages (지키기 어렵다)
> 메시지가 스스로 설명 해야한다.
> 메시지만 보고 무슨 뜻이지 모두 알아야한다.
Ex)
(1) GET / HTTP /1.1
은 self-descriptive 한가? No, 목적지가 빠져있기 때문에 안된다.
-> 다음과 같이 수정 필요
GET / HTTP /1.1
Host: www.test.co.kr
은 self-descriptive 하다.
(2) HTTP/1.1 200 OK
[ {"op": "remove", "path": "a/b/c/" }
은 self-descriptive한가 ? No, Client가 해석을 못한다.
-> 다음과 같이 수정 필요
HTTP/1.1 200 OK
Content-Type: application/json-path+json
[ {"op": "remove", "path": "a/b/c/" }
은 self-descriptive한다.
이유는 Content-Type의 application/json-path+json 명세를 통해서
body 내용을 해석 할수 있기 때문이다.
4) hypermedia as the engine of application state(HATEOAS) (지키기 어렵다)
> application의 상태는 Hyperlink를 이용해서 전이 되어야한다.
Ex)
(1) HTML은 HATEOAS를 만족한다. a 태그를 통해서 Hyperlink를 사용한 상태 전이가 가능하다.
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head></head>
<body><a href="/test">test</a></body>
<html>
(2) JSON은 HTTP의 Link header를 통해서 HATEOAS를 만족시킬 수 있다.
HTTP/1.1 200 OK
Content-Type: application/json
Link: </article/1>; rel="previous",
</article/3>; rel="next";
{
"title": "The second article",
"contents": "blah blah.."
}
> HATEOAS는 다음 그림과 같이 링크를 통해서 상태 전이가 되어야 한다는 것을 말한다.
4. 왜 uniform interface를 해야 하는가?
- 독집적 진화
1) 서버와 클라이언트가 각각 독립적으로 진화한다.
2) 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
3) REST를 만들게 된계기 : "How do i improve HTTP without breaking the web"
5. REST를 사용한 사례
- 웹
1) 웹 페이지를 변경했다고 웹 브라우저를 업데이트 할 필요는 없다.
2) 웹 브라우저를 업데이트했다고 웹 페이지를 변결 할 필요도 없다.
3) HTTP 명세가 변경되어도 웹은 잘 동작한다.
4) HTML 명세가 병경되어도 웹은 잘 동작한다.
6. REST API?
- REST 아키텍쳐 스타일을 따르는 메시지를 통해 Resource에 접근하는 API
- REST API에 대한 비공식 적인 가이드가 RESTfull API이다.
7. JSON으로 하이퍼 링크를 표현하는 방법을 정의한 명세들을 활용
1) JSON API
2) HAL
3) UBER
4) Siren
5) Collection+json
8. 정리
1)오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
2)REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못한다.
3)REST는 긴 시간에 걸처 진화하는 웹 애플리케이션을 위한 것이다.
4)REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야한다.
5)REST를 따르겠다면 Self-descriptive와 HATEOAS를 만족시켜야한다.
- self-descriptive는 cumstom media type이나 profile link relation
등으로 만족시킬수있다.
- HATEOAS는 HTTP 헤더나 본문에 링크를 담아 만족 시킬수 있다.
참조 강좌 : https://www.youtube.com/watch?time_continue=1073&v=RP_f5dMoHFc
참조 사이트 : http://meetup.toast.com/posts/92
'프로그래밍 > web Programming' 카테고리의 다른 글
| [Maven] 2. Maven 프로젝트 설정 (0) | 2018.09.15 |
|---|---|
| [Maven] 1. Maven 프로젝트 만들기 (1) | 2018.09.15 |
| Web API란? (0) | 2018.08.23 |
| [MySQL] MySQL DB 기본 사용법 (0) | 2018.07.25 |
| [WebTool] URL Shortener and Link Management Platform (2) | 2018.06.24 |