REST API - Uniform Interface

JUNHO YEOM·2023년 2월 6일

개념

목록 보기

5/6

Rest API란?

URI를 통해 자원을 지정
HTTP 메서드: 자원에 대한 행위 표현

CREATE |  POST  | /user
READ   |  GET   | /user/1
UPDATE |  PUT   | /user/1
DELETE | DELETE | /user/1

REST란!?

REST 아키텍쳐 스타일에 부합하는 API
HTTP메서드가 REST아키텍쳐가 아니라, HTTP 메서드는 REST가 아니라 웹의 아키텍쳐 스타일의 일부다.

Rest 제약 조건

Client-Server
Stateless
Cache
Uniform Interface
Layered System
Code-On-Demand

Uniform Interface

1.자원의 식별(identification of resources)
2. 표현을 통한 자원의 조작(manipulation of resources through representations)
3. 자기 서술적인 메시지(self-descriptive messages)
4. HATEOAS (hypermedia as the engine of application state)

자원의 식별(identification of resources)

자원

이름을 지닐 수 있는 모든 정보
개념적인 대상
ex) 문서, 이미지, 자원들의 집합, 실존하는 대상 등

자원은 객체입니다.
상태는 변화 가능하기 때문에 변하지 않는 식별자가 필요!

서버의 개별 자원에 대한 고유한 식별자로 URI를 사용해야 한다.
ex: /user/1(DB의 user자원에 대해 특정할 수 있음)

표현을 통한 자원의 조작(manipulation of resources through representations)

기본적으로 자원은 개념적인 대상이기 때문에 하나의 자원에 대한 데이터는 다양한 방식으로 표현될 수 있습니다.

예: 문서, 파일, HTTP 메시지 엔티티 등

ex) 이미지라는 자원의 기대되는 초기 상태를 이미지 파일이라는 형태로 표현하고, 이 표현을 담은 POST 요청을 서버로 보내면, 서버에서는 이 표현을 바탕으로 새로운 이미지 자원을 생성하고, /image/1이라는 URI를 해당 자원에 대한 식별자로 할당을 합니다.

특정 시점에 자원이 지니고 있는 상태를 특정한 방식으로 표현하고, 그 표현을 클라이언트와 서버가 서로에게 전송한다는 것이
REpresentational State Transfer 한다는 것입니다.

REpresentational State Transfer
표현된(자원의)상태

자원의 현재 상태
자원의 기대되는 상태

자기 서술적인 메시지(self-descriptive messages)

클라이언트와 서버 사이의 컴포넌트들은
메시지의 내용을 참고하여 적절한 작업 수행합니다.

클라이언트가 보낸 요청이 네트워크 어딘가에 존재하는 특정한 서버에 정확하게 도착하고, 서버의 응답메시지가 다시 클라이언트에 도달할 수 있는 것은 컴포넌트들의 순차적인 도움 덕분에 가능합니다.
이때 클라이언트와 서버에서 보내는 요청및 응답 메시지들은 이 컴포넌트들, 중개자들에게 자신을 어떻게 처리해야 하는지에 대해 제대로 설명해야 한다는 것이 이 의미입니다.

예시1. 요청메시지의 Host헤더 필드 도메인

요청 메시지의 경우 Host 헤더 필드에 도메인명을 기재하여 어디로 보낸 요청이다에 대한 정보를 포함시켜 줘야만 자기 서술적인 메시지다 라고 이야기 할 수 있을 것입니다.

Host헤더에는 도메인명이 반드시 필요해요

HTTP/1.1부터 Host헤더가 없는 경우 서버에서 요청을 거절해야 한다는 스펙이 명시되었습니다.

IP주소 뿐만이 아니라 도메인명 정보가 명시되어야 하는 이유

가상호스트 문제

하나의 IP 주소에 복수의 도메인명 존재 가능

IP 주소만으로는 요청 대상을 정확히 찾아낼 수 없기 때문

예시2. 캐시

캐쉬 관련 헤더를 통한 캐쉬 전략 지정

기본적으로 개별 요청에 대한 응답은 클라이언트와 서버 사이의 특정 컴포넌트에 일정기간 동안 캐시에 넣는 경우,
두번째 요청 부터는 서버까지 가서 찾는 것이 아니라 해당 컴포넌트로 부터 캐시된 정보를 바로 제공받을 수 있었습니다.

HTTP/1.1(부터 지원): Cache-Control, Age, Etag, Vary

HATEOAS (hypermedia as the engine of application state)

홈, 이메일, 이미지의 3가지 페이지로 구성된 사이트가 있습니다.

기본적으로 저희는 각 페이지에 대응대는 URI를 입력하고 엔터를 입력해서 각 페이지에 접근할 수 있습니다.
다른 방법으로는

화면에 랜더링된 HTML의 앵커 태그등을 활용하여 해당 페이지로 이동 하는것 도 가능합니다.
이처럼 URI를 통해 이동하거나, 앵커태그등을 통해 이동하는것을 모두 Application의 상태를 변경하는 것이라고 이야기 합니다.

HATEOAS하기 위해서는, HTML과 같은 하이퍼미디어를 통해 클라이언트가 애플리케이션을 변경할 수 있는 인터페이스를 제공해야 한다는 것입니다.

서버에서 앵커 태그들이 담긴 HTML을 클라이언트에 그대로 전송한다면, HATEOAS에 위배되지 않을 것 입니다.
하지만 보통 우리의 Application은
하지만 우리의 API들은 프론트앤드와 백엔드간의 Data통신시에 JSON을 통해서 화면의 요소를 구성하게 됩니다.
백엔드 서버의 API는 HATEOAS를 위배하게 될 수 있습니다.
이를 피하기 위해 JSON에 서버에 보낼 수 있는 요청들에 대한 정보를 포함시켜서 클라이언트에 전달할 수 있으면 HATEOAS에 위배되지 않는것입니다.

예시는 다음과 같습니다.