REST API

moontag·2022년 6월 10일

REST API

네트워크

목록 보기

8/18

로이 필딩 선생님,,,,

참고 영상

기초 영상
심도 있는 영상 - 이 영상을 주로 참고하여 포스팅했습니다

1. REST API의 등장

REpresentational State Transfer

2000년, 로이 필딩 Roy T. Fielding의 박사 논문으로 발표됐고, 로이는 HTTP 1.0과 1.1의 주요 저자 중 한 사람이다.
REST는 과거 SOAP이란 복잡한 방식을 대체하고자 나왔다.
먼저 REST API는 웹에서 사용되는 자원(Resource)를 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청/응답을 정의하는 방식이다.

📝 쉽게 말하자면 모두가 읽기 편한 메뉴판

❌ 유저, 팀 동료가 이해하기 힘든 표준 없는 API

GET /movies/create/1
GET /deleteMovie/inception
GET /findMoviesFromThisYear

⭕️ 모두 이해하는 직관적 API

(메서드 /collection/ element)
GET /movies/
PUT /movies/inception/actors

리소스는 collection 과 element 으로 나눠 표현할 수 있다.

collection
http://example.com/resources/
element
http://example.com/resources/item17

Q, 개발자들이 말하는 REST API? RESTful API란?

HTTP 규약에 따라 통신하고, 각 요청이 어떤 동작과 정보를 원하는지 메시지 자체로 설명가능한 것.

HTTP 요청 시, 식별자 URI에 정보의 자원을 표현하고
HTTP Method로 CRUD(Create Read Update Delete) 작업을 표현하여 사용한다.

Q, REST를 만든 Roy 입장에서 찐 REST API란?

REST API
: REST 아키텍쳐 스타일(제약조건 모두 지키는) 따르는 API.
REST 란?
: 분산 하이퍼미디어 시스템(예:웹)을 위한 아키텍쳐 스타일(제약조건의 집합)

REST의 구성 요소

client-server
stateless
cache
latered system
code-on-demand(optional)
uniform interface ✅ 이것을 놓치는 경우가 많다

Uniform Interface 제약조건 중 주로 못지키는 2가지

Self-descriptive : 메시지만 봐도 자체 설명이 돼야 함
HATEOAS : 애플리케이션 상태가 Hyperlink를 이용해 전이돼야 함

2. Self-descriptive와 HATEOAS, 왜 지켜야 하는가?

= 서버와 클라이언트의 각각 독립적 진화 위해서.

1. self-descriptive

확장가능한 커뮤니케이션
서버나 클라이언트가 변경돼도 메시지는 언제나 해석 가능하므로 서버는 계속 변경할 수 있다.

2. HATEOAS

애플리케이션 상태 전이의 late binding
서버가 링크를 동적으로 변경할 수 있다. 클라이언트는 바뀐 링크를 보고 따라가면 되기 때문이다. 그래서 애플리케이션 상태가 Hyperlink를 이용해 전이돼야 한다.

= 서버,클라이언트가 각각 독립적으로 진화해야 한다.
그러면 서버 기능이 변경되어도 클라이언트를 업데이트할 필요가 없기 때문이다.

<REST 잘 적용된 사례>
= Web
웹 페이지나 브라우저 변경했다고 브라우저 업데이트하거나 페이지를 변경할 필요가 없다

<REST 잘 적용안된 사례>
= App
업데이트 계~속 해야하는 것

Roy는 REST를 쓴다면, REST API 제약조건 다 지켜야 한다고 말한다.
하지만!! 꼭 REST API여야만 하는 것은 아니다
시스템 전체에 통제가 가능하고, 독립적 진화(앱 매번 업데이트..)에 관심없으면 REST 하지 마라.

3. 진짜 REST API 구현하기

Q. 왜 API는 REST가 잘 안될까?

	Web page	HTTP API
Media Type	HTML	JSON
Hyperlink	`<a>` 태그로 링크 걸 수 있음	링크 없음
셀프 설명	html 명세로 정의되어 있음	밑에 사진 예시를 들면 id, title에 대한 의미 설명되어 있지 않아서 불완전함

3-1. JSON을 REST API로 바꿔보기

1) Self-descriptive

1. IANA에 Media type 정의

미디어 타입 문서를 작성하는데 여기에 id, title의 의미를 정의한다. 이 문서를 명세로 등록하면 메시지를 보는 사람이 명세를 찾아가므로 메시지 의미를 해석할 수 있다. 미디어타입 등록이 필수는 아니다.

단점 - 매번 정의해야 하는 번거로움이 있다

2. Profile

id, title의 정보가 담긴 명세 작성해 Link 헤더에 profile relation으로 명세를 링크한다. 메시지를 보고 명세 링크를 볼 수 있으므로 문서의 의미를 해석할 수 있다.

단점 - content 협상을 할 수 없다. 그리고 클라이언트가 Link 헤더와 profile을 이해해야한다

2) HATEOAS

data, header를 모두 활용하면 좋다

1. data로 하이퍼링크 정의

1-1) 링크 표현 방법을 직접 정의

단점 - 링크를 직접 정의해야한다

1-2) 하이퍼링크를 표현하는 방법을 정의한 명세들 활용
(JSON API, HAL, UBER, Siren, Collection+json 등).

단점 - 명세 요구사항에 맞게 구현해야해서 기존 API를 많이 고쳐야 한다.

2. HTTP 헤더로

Link, Location 등의 헤더로 링크 정의한다.

단점 - 정의된 relation만 활용하면 표현에 한계가 있다.

❤️‍🔥 정리

대부분 진짜 REST 따르지 않는다.
이유 : 제약조건 중 Self-descriptive와 HATEOAS를 잘 지키지 못하기 때문에
REST는 수십년 진화하는 웹 애플리케이션 위한 것
REST를 따를 건지는 API 설계자들이 스스로 판단해서 결정해야한다.
REST를 따를거면, Self-descriptive와 HATEOAS를 지켜야한다.
1. Self-descriptive는 custom media type이나 profile link relation 등으로 만족 가능하다.
2. HATEOAS는 http 헤더나 본문에 링크를 담아 만족 가능하다.
REST를 안따를거면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야 할 것이다.
- HTTP API라 부를 수 있고
- 그냥 REST API라고 부를 수도 있다. (REST를 만든 roy가 싫어한다)
- RMM(Richardson Maturity Model:성숙도모델)의 0~3단계에서
  2단계까지 준수한 것을 HTTP API,
  3단계까지 준수한 것을 REST API라고 부른다