REST API 란?

HTTP 란?

-HyperText Transfer Protocol 의 준말로 링크 기반의 데이터를 요청하고 받겠다는 것

-클라이언트와 서버가 요청/응답을 하기 위해 사용하는 프로토콜

-HTML 문서를 교환 할 수 있음, 이미지,동영상, 오디오, 텍스트 문서등...

 

HTTP Method 및 REST API

메소드란?

요청의 종류를 서버에 알리기 위해 사용하는것, 게시판 기능(CRUD, REST API)을 만들때 사용

#메소드 종류

GET: 정보를 요청하기 위해 사용(READ)

POST: 정보를 입력하기 위해 사용(Create)

PUT: 정보를 업데이트하기 위해 사용(UPDATE)

DELETE: 정보를 삭제하기 위해 사용(DELETE)

 

REST API 란?

-HTTP 프로토콜의 장점을 살릴 수 있는 네트워크 기반 아키텍처

-HTTP 메서드 + 모든 개체 Resource화 + URL 디자인(라우팅) 필요

-라우팅이란? 클라이언트의 요청에 대한 결과를 어떻게 이어줄 것인가를 처리하는것

-URL을 통한 접근: 모든 개체를 리소스를 보고, 리소스에 고유번호 부여

-URL 디자인 원칙: 자원에 대한 처리를 주소에 나타내지 않음(HTTP 메서드는 내부적으로 처리하도록), 어떤 자원인지 주소에 명확하게 나타냄

-REST API를 구현하기 위해 1.HTTP 프로토콜에 대한 이해, 2.메서드 종류, 3.라우팅 에 대한 이해가 있어야함.(추후 카페 정리 예정)

 

API의 본질은 무엇인가? Decoupling, 탈 동조화

그렇다면 Web API의 본질은 무엇인가? Decoupling + PLATFORM Agnostic

*PLATFORM Agnostic : 플랫폼에 종속적이지 않음
즉, 특정 기기나 OS 에서만 돌아가는 것이 아는 광범위하게 사용될 수 있는것. 

 

그래서 REST 는?

REST(Representational State Transfer), 웹에 존재하는 모든 자원에 고유한 URI를 부여하여 사용하는 것으로,

자원을 정의하고 자원에 대한 주소를 지정하는 방법론을 의미

따라서 RESTful API는 REST 특징을 지키면서 API를 제공하는 것을 의미

 

HTTP 1.0이후 웹의 성공으로 인해 HTTP 프로토콜의 의도에 맞지 않는 사용으로 인한 확장성이나 유지보수성이 좋지않은 웹이 늘어나면서 REST 가 주목받기 시작함.

["아래의 6가지 조건을 REST라고 하며, 이를 잘 지키는 서비스 디자인을 보고 RESTful 하다고 한다."]

1.  Uniform Interface
2.  Client-Server
3.  Stateless
4.  Cacheable
5.  Layered System
6.  Code on Demand(optional)

 

REST 구성

Richard Maturity Model(RMM)

 

[LEVEL 0]

웹의 기본 메커니즘을 전혀 사용하지 않는 단계로, HTTP를 통해 데이터를 주고 받지만 모든 데이터 요청/응답과 관련한 정보를
HTTP의 BODY 정보를 활용한다. 
HTTP 메서드는 POST 만 사용하며, 특정 서비스를 위해 클라이언트에서 접근할 endpoint는 하나이다.
즉, 하나의 URI를 가지고 하나의 HTTP 메서드를 사용한다.

 

[LEVEL 1-RESOURCE]

RMM에서 REST를 위한 첫 단계는 리소스를 도입하는 것.

이제는 모든 요청을 단일 서비스 endpoint로 보내는 것이 나닌 개별 리소스와 통신한다.

즉, 함수를 호출하고 인자를 넘기는 것이 아닌, 다른 정보를 위해 인자들을 제공하는 특정 리소스로 요청을 보낸다.
자원이 외부에 보여지는 방식과 내부에 저장되는 방식을 분리할 수 있는 장점이 있다.
ex)
클라이언트 단에서 완전히 다른 포멧으로 저장하더라도 JSON 형태의 데이터를 요청할 수 있다,
다양한 URI를 사용하지만 HTTP 메서드는 하나만 사용한다. 그나마 URI를 통해 요청이나 파라미터를 명시한다.

 

[LEVEL 2-HTTP Method]

LEVEL1 의 URL + HTTP Method 조합으로 리소스를 구분하는 것으로 응답 상태를 HTTP Status code를 활용한다.

현재 가장 많은 RESTful API가 이 단계를 제공한다.

발생한 에러의 종류를 커뮤니케이션 하기 위해 상태코드(Status Code)를 사용하는 것, 그리고
안전한 오퍼레이션(GET)과 안전하지 않은 오퍼레이션 간의 강한 분리를 제공하는 것이 레벨2의 핵심요소.

 

*Status Code를 사용한다는 것은 어떤 의미일까?

기존에는 유저 생성 요청을 했을 경우 302 등의 Redirect Request를 서버에서 내려주는 방식이었다면,

지금은 201(created)로 유저 생성 성공을 알릴뿐, 페이지 이동은 클라이언트 단에서 해결하는 방식

(로그인 성공은 200, 실패 시 인증 실패는 401, 성공했으나 권한 문제시엔 403)

즉, 서버는 순수하게 API로서의 기능만을 제공

 

*강한 분리를 제공하는 것은 어떤 이점이 있나?

HTTP 에서 GET은 멱등방식으로 자원을 추출,

즉, 호출 순서나 횟수에 영향을 받지 않고 매번 같은 결과를 받을 수 있음

그렇기 때문에 모든 Request에 "캐싱" 기능을 지원하는 다양한 방법을 제공

*Idempotent(멱등)개념이 왜 등장했나?

REST는 각 개별 API를 상태 없이 수행하게 된다. 따라서 해당 REST API를 다른 API와 함께 호출하다 실패하였을 경우 트랜잭션 복구를 위해 다시 실행해야 하는 경우가 있다.
Idempotent 하지 않은 메서드들의 경우는 기존 상태를 저장 했다가 다시 복원해줘야 하는 문제가 있으나, 멱등한 메서드의 경우 반복적으로 다시 메서드를 수행해주면 된다.
예를 들어)
게시물 조회를 하는 API가 있을 때, 조회 시 마다 조회수를 올리는 연산을 수행한다면 해당 메서드는 Idempotent 하다고 볼 수 없고 조회하다가 실패 하였을땐 올라간 조회수를 다시 -1만큼 빼줘야 합니다. 
즉 Idempotent 하지 않은 메서드에 대해선 트랜잭션에 대한 처리를 특히 주의가 필요하다.

 

[LEVEL 3-HyperMedia Control]

 

*하이퍼미디어란

하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포맷이 컨텐츠를 링크하는 개념이다.
이것은 관련 컨텐츠를 보기 위해 링크를 따라가는 방식과 유사한 방식으로 동작하는데
클라이언트가 다른 자원에 대한 링크를 통해 서버와 상호작용을 한다.
즉, 특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며, 다음 단계의 작업을 위한 리소스의 URI를 알려주는 것이다.
이단계를 적용하면 클라이언트에 영향을 미치지 않으면서 서버를 변경하는 것이 가능하다

 

단점은 클라이언트가 수행할 작업을 찾기 위해 링크를 따라가기 때문에 컨트롤 탐색에 꽤 많은 호출이 발생할 수 있다.

또한 복잡성이 증가할 수 있으며, HTTP 요청 상에 나타나는 부하로 지연시간이 요구될 때 문제가 될 수 있다.

HTTP기반의 REST payload는 JSON 또는 바이너리 등의 포맷을 지원하므로 실제로 SOAP 보다 훨씬 간결할 수 잇지만

Thrift와 같은 바이너리 프로토콜에는 상대가 되지 못한다. 

또한 WebSocket의 경우 HTTP 초기 핸드쉐이크 후에 클라이언트와 서버간에 TCP 접속이 이루어지고 브라우저에서 스트림 데이터를 보낼 때 효울적일 수 있다. 따라서 HTTP가 대규모 트래픽에는 적합할 수 있으나 TCP 또는 다른 네트워킹 기술 기반의 프로토콜과 비교하면 낮은 지연시간이 필요한 통신엔 그다지 좋은 선택이 아닐수 있다.

이러한 단점에도 HTTP 기반의 REST는 서비스 대 서비스의 상호작용을 위해 합리적이고 기본적인 선택이다.

 

 

출처:ijbgo.tistory.com/20#recentComments