Rest?, RESTful API?란...

SaGo_MunGcci·2022년 7월 28일

TIL

스프링

목록 보기

3/31

Definition Access

이 개념을 접근하게 된 계기는 http 아키텍처를 공부하면서 알게 되었다.
과제를 해결하면서도 필요한 개념이었다.
클라이언트와 서버간의 통신이 왜 이렇게 이루어 지는 지 공부하고 싶었다.
스프링을 사용하면서 백앤드의 전반적인 구조와 작동방식을 이해하기 위해서는 반드시 필요한 개념인것 같았다.

참고 : |로이 폴딩의 논문 | https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

참고 : |MDN http 공식 문서 | https://developer.mozilla.org/ko/docs/Web/HTTP/Overview

Mechanism

1.Rest

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 소개했는데 그것이 바로 Representational safe transfer (REST)이다.

REST는 HTTP 표준에만 따른 다면, 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일이다.

1) Rest의 특징 (6가지 항목)

Uniform interface (유니폼 인터페이스)
- REST는 HTTP 표준에만 따른 다면, 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일이다.
- 개발자가 개발할 어플리케이션의 설계가 http + json으로 되어있으면 android,ios,java,c등 특정한 플래폼이나 언어에 종속 되지않고 http + json을 사용할 수 있는 모든 플랫폼에 사용이 가능한 느슨한 결함(Loosely coupling) 형태의 구조이다.
- 단 반드시 json을 사용해야만 하는 것은 아니다. json이 워낙 범용성이 있어서 사용하지만 개발에 필요한 형식을 사용해도 된다.
Stateless (무상태성)
- http를 공부했을때 배웠던 비상태성이다. 즉 서버와 클라이언트는 한번 요청받고 응답하면 끝난다. 기본적으로 클라이언트가 요청한것은 계속적으로 요청하기 위해서는 응답이 끝나고 다시 요청해야된다.(클릭을 2번해야 된다) 우리가 대화를 자연스럽게 하는 것처럼 연결되어있지 않다.
Cacheable (캐시 가능)
- http는 요청-응답의 1개 묶음으로 계속적인 통신을 하지만 만약 요청이 방금했던것이라면 다시 반복하지만 http는 Cache라는 임시저장소를 제공한다. 따라서 방금 요청한 것을 서버까지 가는 대신 이미 처리해놓은 결과를 다시 보내 줄 수있다.(http는 캐시를 포함하는 통신인것이다!)
- 이렇게 캐쉬를 사용하게 되면 네트웍 응답시간 뿐만 아니라, REST 컴포넌트가 위치한 서버에 트렌젝션을 발생시키지 않기 때문에, 전체 응답시간과 성능 그리고 서버의 자원 사용률을 비약적으로 향상 시킬 수 있다.
Self-descriptiveness (자체 표현 구조)
- 더 자세히 논하기 위해 아래에 후술 하겠다.
Client - Server 구조
- REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다.
- 클라이언트의 경우 사용자 인증이나 컨택스트(세션,로그인 정보)등을 직접 관리하고 책임 지는 구조로 역할이 나뉘어 지고 있다.
- 이렇게 역할이 각각 확실하게 구분되면서, 개발 관점에서 클라이언트와 서버에서 개발해야 할 내용들이 명확하게 되고 서로의 개발에 있어서 의존성이 줄어들게 된다.
계층형 구조
- 계층형 구조는 인접한 2개의 부분이 서로에게만 영향을 주고 다른 부분은 영향을 줄 수없는 아키텍처 패턴중 하나이다.
- 계층형 아키텍쳐 구조 역시 근래에 들어서 주목받기 시작하는 구조이다
- 클라이언트 입장에서는 REST API 서버만 호출한다.
- 서버는 다중 계층으로 구성될 수 있다. 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증 (Authentication), 암호화 (SSL), 로드밸런싱등을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있다.

2) Self-descriptiveness (자체 표현 구조)

REST의 가장 큰 특징 중의 하나는 REST API 자체가 매우 쉬워서 API 메시지 자체만 보고도 API를 이해할 수 있는 Self-descriptiveness 구조를 갖는 다는 것이다.
리소스와 메서드를 이용해서 어떤 메서드에 무슨 행위를 하는지를 알 수 있으며, 또한 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조이다.

좀더 이 말들을 쉽게 풀어 쓰면, 다음과 같이 된다.

“HTTP URI로 잘 표현된 리소스(자원)에 대한 동작 및 행위를 HTTP 방식으로 정의하는데, 이 때 자원의 내용은 JSON, XML 등 다양한 언어로 표현 가능하다.”
이 말을 조금 더 짧게 정리하자면
: HTTP URI로 정의된 리소스를 HTTP 방식과 페이로드의 결합으로 정의한 API --> 페이로드 그 바디에 들어있는 페이로드인것 같다.
이 특징에 3가지 요소가 있는데 바로 자원(리소스),행위(httpMethod),표현이다.

a) 리소스(Resource, 자원)

리소스는 REST API의 수행(처리해야 할) 대상이다. 여기서 리소스는 한국어로 ‘자원’이라는 의미를 갖는데, JSON, XML 등의 문서 뿐만 아니라, jpg, avi 등 미디어 형식일 수도 있다. 유니폼 인터페이스와 같이 자원은 반드시 json형식만 써야 하는 것은 아니다.

웹 상에서 이러한 리소스들은 URI를 통해 표현 된다.

예를 들면, http://www.youtube.com/user1/video라는 URI가 있다고 가정하자. 이 URI를 통해 도출할 수 있는 것은 ‘user1’이라는 사람이 ‘video’라는 파일을 등록했다는 것이다.

b)메소드(Method, 방식, 행위)
REST API의 가장 큰 장점은 메소드에서 나온다.

바로 “리소스에 대한 행위가 일관적(Uniform)“이기 때문인데, 조금 더 풀어서 설명하자면 “REST API가 다루는 리소스가 어떠한 종류(문서, 비디오, 음악, 이미지 등)이던지 상관 없이, 모두 같은 메소드로 동작“한다고 생각하면 된다.

http메서드의 종류

POST: 서버에 데이터를 추가, 작성 등

PUT: 서버의 데이터를 갱신, 작성 등

GET: 서버로 부터 데이터를 조회

DELETE: 서버의 데이터를 삭제

PATCH: 리소스의 일부분을 수정

.....................................................여기까지가 기본 httpMethod이다..............................................

HEAD: 서버 리소스의 헤더(메타 데이터의 취득)

OPTIONS: 리소스가 지원하고 있는 메소드의 취득

CONNECT: 프록시 동작의 터널 접속을 변경

위의 메서드만으로 웹을 사용하고 있는 것이다.

c) 표현

http://15.164.169.213/new/student 라고 했을때 이것이 뭔가 신입생에 관한것이라고 생각은 드는데(여기까지도 상당히 괜찮은 restful한 Api라고 생각한다) 정확히 뭘하는 지는 모를 수 밖에없다.
만약 위 주소에 1,2,3학년각 클래스의 28번의 사진을 가져오고 싶다면 어떻게 리소스에서 표현할 수있을까?

GET http://15.164.169.213/grade/1/28/HTTP/1.1 Accept:image/student.jpg
GET http://15.164.169.213/grade/2/28/HTTP/1.1 Accept:image/student.jpg
GET http://15.164.169.213/grade/3/28/HTTP/1.1 Accept:image/student.jpg
?????????????????? 반복해야 된다???????????

HTTP 메소드와 URI만 가지고는 사용자가 원하는 정보를 반환하는 것에 한계가 있을 수 밖에 없다.

또한 사용자는 이름, 직업, 나이, 성별 등 다양한 특성들을 가질 수 있는데, 위와 같은 단순한 POST 문구로는 그러한 특성들을 담는 것이 상당히 어려울 것이다.
결국 이러한 세부 특성을 표현하기 위해 JSON, XML 등의 언어를 사용하는 것이다.
그리고 이러한 언어로 표현되는 부분은 ‘페이로드(Payload), 또는 바디(Body)’ 라고 한다.
사용자는 이러한 페이로드 부분을 여러가지 언어로 표현할 수 있다.
단순히 REST API 헤더 부분에 ‘Content-Type: application/json’과 같은 내용을 추가해주면 페이로드를 해당 언어로 해석할 수 있게 되는것이다.

즉 해당 리소스의 한계를 극복하기위해서 json이라는 표현을 빌려서 데이터를 요청하고 응답하는 것이다.
Json을 왜 사용하는 지 이제 알겠네..... 그냥 막연하게 데이터를 보내는게 편리해서가 아니라 이런 http의 구조적인 한계 즉 리소스와 행위적으로 한계가 있기때문에 해당 표현의 형식으로 Json이라는 것을 사용하는 것임.

2.Restful

RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 한다.
즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭된다.
해당 리소스까지는 어느정도 이해하는 것까지 설계하고 그에 해당하는 데이터를 정확하게 응답해줘야 할 수있는것이 Restful하게 api를 만드는 것이다.
rest예시에서 각학년의 28번 학생의 사진을 조회할때 각학년에서 데이터를 가져오는 것이 아닌 all이라는 리소스를 설계하고 그에맞는 json데이터를 보여주면 된는 것이 restful한 api설계이다.

GET http://15.164.169.213/grade/all/28/HTTP/1.1 Accept:image/student.jpg