REST / REST API란❔

 REST API 란❔

 

흔히 우리는 흔히 REST , RESTful 이라는 말을 많이 들어봤다.

일반적으로 데이터를 주고 받는 통신을 할때 한다는 것을 알고 있다. 그럼 이 용어가 무엇을 의미하는지 한번 알아보자

1. REST

REST는 Representation State Tranfer 의 약자이다. 쉽게 말하자면 자원의 약자로 이름으로 구분하고 자원의 상태를 전이한다는 의미를 가진다.

그럼 왜 REST가 대중화 되었을까? 그러기 위해서  SOAP 아키텍처에 대해서 간단히 알아보자

👉 SOAP 

SOAP 아키텍처는 웹 개발을 막 배우기 시작한 시점에 처음 접하게 될 것이다. 

용어를 정리하면 Simple Object Access Protoco 이라고 한다. 즉 XML 기반의 메시지를 전달하는 방식이다.

Spring MVC에서 템플릿 엔진을 사용해서 모델에 데이터를 저장하고 뷰를 렌더링 하는 방식으로 개발한 경험이 있을 것이다.

이 방식이 SOAP 아키텍처이다. 이떄 클라이언트와 서버의 통신은 데이터만 넘겨주지 않는다. HTML을 만들어서 클라이언트 즉 브라우저로 넘겨주는 방식이다. 자 이 방식은 어떤 한계점이 있을까?

일단 XML 사용이라는 제한때문에 오버헤드나 복잡함을 경험 할 수 있다.

 

👉 REST 프로토콜

그럼 이제 REST 프로토콜을 알아보자

이름을 해석하면 자원의 약자를 이름으로 구분하고 자원의 상태를 전달한다 라고 했다.

그럼 이 과정이 어떻게 진행되는지 순차적으로 한번 알아보자

 

◾ 자원 이름 정의

대표적으로 우리의 웹 통신 방식 떠올려보자

URI를 통해서 브라우저에서 어떤 링크를 입력하면 뭔지는 모르겠지만 뭔가 화면이 바뀐다.

이 과정에서 자원 이름을 정의하게 된다.

자원의 이름 즉 URI ( Uniform Resource Identifier ) /users 라고 하면 사용자 목록을 나타내는 자원입니다.

 

◾ 상태 전이

상태 전이란 이 URI 로 우리는 POST, DELETE, PATCH 등 HTTP 메서드로 요청을 보내고 이 서비와 클라이언트의 상호작용을 통해서 서버의 자원에 상태를 전이한다.

 

예를 들어서 /users/1 이라는 URI 로 DELETE 를 보내면  서버에 자원에서 1번이라는 ID를 가진 사용자의 자원을 삭제 한다. 즉 CRUD 작업에 대한 상태를 서버로 전이 시키는 것이다.

👉 HTTP 메서드
1. GET : 자원을 조회할때 사용
2. POST : 자원을 생성 할 때 사용
3. PATCH/PUT : 자원을 변경 할 때 사용
4. DELETE : 자원을 삭제 할 때 사용

✅ PUT/ PATCH
PUT/PATCH 모두 자원의 정보를 변경하는 것에 목적을 가진다
두개는 무슨 차이가 있을까? 
결정적으로 두개의 차이는 멱등성을 보장하는냐이다. 즉 자원의 상태를 일관적으로 유지하냐 이다.

예시를 들어서 생각해보자
PUT을 통해서 자원에 전체 정보를 변경했을떄 다른 사용자가 거기에 접근하더라고 모든 정보가 PUT을 통해서 업데이트 된 상태거나 아니거나 둘 중 하나이다. 이 경우 자원의 멱등성이 보장된다.

하지만 PATCH는 사용자 정보중 이름만 바꿨다고 가정해보자
이때 다른 유저가 만약 이메일로 변경을 했다고 하면 1번 PATCH 요청은 이름만 바꿨지만 결과적으로 데이터는 이름과 이메일이 모두 변경된 것이다.
즉 자원이 요청을 보내도 결과가 동일하게 유지된 다는 것을 보장할 수 없다.

실제 정의는 이렇지만 결국 값을 일부만 수정하느냐 아니냐의 차이라고 볼  수 있다.
회워 정보를 변경할 때 PUT 으로 하느냐 PATCH로 해야하냐 이런식으로 고민할 것 같은데
나라면 PUT으로 변경을 할 것 같다.
사용자가 현재 페이지에서 자신이 수정한 내용 전체를 DB에 반영하고 그 정보가 그대로 유지되야 하는 상황은 멱등성이 고려되야 한다고 보이기 때문이다.

 

◼ REST 구성 요소

REST는 총 5 가지를 가진다

1. 자원 (Resources)

서버에 어떤 자원을 변경 할지 이다. 

사용자라면 /users, /orders 와 같은 자원 이름 또는 별칭이다.

 

2. HTTP method 

GET, POST, PATCH, PUT, DELETE 와 같은 자원에 수행할 동작

 

3. 표현 (Representation)

자원에 상태를 전달하는 방법이다.

일반적으로 JSON 을 대부분은 사용한다.

{
  "id": 1,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

 

4. 상태

서버가 클라이언트에게 보내주는 요청을 결과 이다.

응답 상태 코드라고 하며 200 OK, 404 Not Found 와 같은 상태 코드이다.

 

5. 링크(Links) 

링크는 하이퍼 미디어를 사용해서 리소스 간의 연결을 제공한다.

클라이언트가 가능한 다음 요청 동작을 자동으로 수행하게끔 해준다.

사실 이 부분은 직접 사용해본적이 없어 가볍게 적고 넘어가겠다.

◼ REST 특징

1. 클라이언트- 서버 아키텍처

클라이언트 - 서버 아키텍처로 구성된다 .클라이언트가 서버에 요청을 보내고 서버는 그에 따른 응답을 다시 보낸다.

요청은 주체는 모든 장치 또는 어플리케이션일 수 있고 서버는 API를 제공하고 클라이언트 요청에 응답하는 어플리케이션을 의미한다. 

이를 통해서 클라이언트 - 서버를 분리하여 개발이 가능하고 유지 보수에 용이하다.

 

2. Statless

무저장 상태를 유지한다. 클라이언트가 서버에 보낸 요청은 이전 요청이나 서버 저장소에 의존하지 않고 모든 요구사항을 요청에 담아서 보낸다. 해당 사항이 인증을 필요로 하는 부분에서 헤더에 인증 토큰을 담아서 보내는 이유이다.

해당 방식을 통해서 요청의 크기가 증가하지만 확장성에서 장점을 가진다.

 

3. 캐시 가능성

서버의 부하를 줄이는 방법 중 하나로 작용한다. 동일한 리소스나 후속 요청에서 응답 시간을 더 빨리 할 수 있도록 캐싱이 가능하다. 이렇게 되면 각 서버 요청에 대한 동일한 응답을 생성할 필요가 없음으로 서버로 로드가 줄어 성능이 향상된다.

 

4. 계층화된 시스템

클라이언트는 단일화된 엔드포인트로 요청을 보낸다. 서버는 여러 백엔드 시스템과 상호작용이 가능하다.

클라이언트에는 영향을 주지 않고 새로운 서버 기능을 추가 가능하고 기존 시스템의 변경이 클라이언트에게는 영향을 주지 않게 하여 유지보수에 용이하다.

추가로 로드밸런싱 등 여러 서버 부하를 줄이는 작업 시에도 클라이언트는 이를 인식할 수 없다.

 

5. 일관된 인터페이스 ( Uniform Interface )

CRUD에 필요한 HTTP 메서드를 사용하며 요청과 응답에 JSON 과 같은 표준화된 포맷을 사용한다.

모든 리소스 및 요청이 일관된 규칙을 따르고 클라이언트가 더 쉽게 API를 이용할 수 있다.

 

2. REST API

REST 가 무엇인지 알았으니 이제 REST API , RESTful API 에 대해서 알아보자

 

◼ REST API

말 그대로 REST 프로토콜을 사용하는 API를 의미한다.

즉 모든 용어로 풀어서 쓰면 REST 방식을 사용하는 어플리케이션 간의 규약 이라고 생각할 수 있다.

REST API는 네이버나 카카오 등 여러 기업에서 제공하는 API가 이런 형식을 따르고 있다.

 

아래는 최근에 사용한 카카오페이 API 이다

카카오페이 | 개발자센터

이런 식으로 요청시 필요한 데이터를 문서화 하였고 여기서 필수로 입력해야하는 값을 입력해서 지정한 HTTP 메서드로 요청을 전달하면 된다.

이런식으로 REST가 정의한 규칙을 따르는 API를 모두 REST API 라고 한다.

 

◼ RESTful API

RESTful 하다는 것은 REST 와 비슷해 보이지만 약간의 차이가 존재한다.

REST 사용한다고 하는 것은 모든 자원 상태 변이를 POST로만 한다고 해도 REST를사용한다고 할 수 있다

하지만 우리는 이런 API 나 시스템은 RESTful 하다고 하지 않는다.

 

즉 REST 사용한다가 아닌 이 REST의 규약을 잘 시키는 경우 RESTful 하다고 한다