🎯 Achievement Goals

RESTful API란?
REST 원칙 및 6가지 특징
RESTful하게 API 디자인을 하는 의미
실제 사용 예제

Intro.

프로젝트를 하면서 서버 개발자와 REST API 디자인에 대해서 많은 논의를 한 경험이 있다. API 설계를 협업을 통하여 결정하고, 자원을 주고 받았다. 하지만 프로젝트를 하는 두 달동안 자주 사용하였어도, 명확하게 설명하기란 쉽지 않았다.

프로젝트에서 많이 활용했던 REST API에 대해서 확실하게 설명할 수 있는 실력을 갖추기 위해 블로깅을 하기로 결심했다!

RESTful API란?

위키백과 정의

월드 와이드 웹(World Wide Web a.k.a WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식으로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반에 대한 패턴

REST는 REpresentational State Transfer의 약자이다. 그래서 REST의 기본 원칙을 지키면서 서비스 디자인을 했다면 ‘RESTful하다’라고 표현할 수 있다.

REST는 웹 서비스의 아키텍처로, API 설계의 중심에 자원(Resource)이 있고, HTTP Method를 통해 자원을 처리하도록 설계하는 것이다. 그래서 이 원칙을 지키면서 API를 설계했다면 RESTful API라고 말할 수 있다.

REST 원칙 및 6가지 특징

REST에서 가장 중요하며 기본적인 원칙은 아래 두 가지이다.

URI는 정보의 자원(Resource)을 표현해야 한다.
자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현한다.

특징은 다음과 같다.

1.Uniform Interface

Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 뜻한다.

2.Stateless (무상태성)

REST는 작업을 위한 상태 정보를 따로 저장하고 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 관리하지 않고, API 서버는 요청만 처리하면 된다.

3.Caching

REST는 HTTP의 기존 웹 표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있다. 따라서 HTTP의 캐싱 기능을 사용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그 또는 E-Tag를 이용하면 캐싱 구현이 가능하다.

4.Client-Server 구조

클라이언트와 서버의 역할이 명확하게 구분되어 있어서 서로간 의존성이 줄어든다.

5.Self-descriptiveness (자체 표현 구조)

REST는 REST API 메시지만 보고도 명확한 의도를 파악할 수 있는 자체 표현 구조로 되어 있다. 즉, 메시지안에 클라이언트가 정보를 어떻게 처리해야 하는지에 대해 충분한 정보가 포함되어 있어야 한다.

6.Hierarchical system (계층적 구조)

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 클라이언트가 볼 수 없는 구조로 체계화할 수 있다.

RESTful하게 API 디자인을 하는 의미

리소스(URI)와 행위(HTTP Method)를 명시적이고 직관적으로 분리한다.
REST API Message는 Header(API 정보, MIME 타입)와 Body(Entity 내용)를 명확하게 분리한다.
API 버전을 관리한다.
서버와 클라이언트가 같은 방식을 사용해서 요청하도록 한다.

실제 사용 예제

실제 사용 예제는 프로젝트에서 직접 사용한 자료를 가져와서 어떻게 사용했는지 소개하려고 한다. REST API는 주로 CRUD 기능을 구현할 때 사용했다.

CRUD 기능을 구현하기 위해 API 설계를 백엔드 개발자와 협업하면서 디자인을 했고, 그렇기 때문에 클라이언트에서 원하는대로 정보를 받을 수 있었다. 주로 사용한 HTTP Method는 GET(조회)과 POST(수정)였고, DELETE까지 사용해보았다.

GET

get_profile

우리는 POSTMAN 사이트를 통해서 API 문서를 제작했다. 위의 API 문서의 내용은 GET(조회) 요청으로, 서버에 요청을 하면 응답으로 유저 프로필의 정보를 받아볼 수 있었다.

프론트엔드였던 나는 서버로부터 유저 프로필의 정보를 받고, 화면에 뿌려주는 작업을 해주면 됐었다. GET 요청은 POST와 달리, 따로 body 부분에 데이터를 담아 줄 필요는 없었다.

위 문서에 나와있는 것처럼 Header 부분에 LoginType과 Authorization 코드만 담아서 요청하면 된다.

const requestData = await axios({
  method: 'get',
  url: `${serverURL}/profile`,
  headers: {
    authorization: `Bearer ${accessToken}`,
    loginType: loginType,
  }
});

// console.log(requestData.data);

API 문서대로 요청을 한다면 위와 같은 코드로 요청하면 된다.

POST

post_profile

POST는 유저의 정보를 업데이트할 때 주로 사용하였다. 유저의 입력값을 가져와서 Body에 담아주고 서버에 요청을 한다. 그러면 업데이트된 정보를 다시 서버로부터 받는다.

서버로부터 업데이트 된 정보를 받으면 나는 다시 그 정보를 화면에 렌더링해주면 되는 것이다.

const requestData = await axios({
  method: 'get',
  url: `${serverURL}/profile`,
  data, // body에 업데이트 할 데이터를 담아서 요청한다.
  headers: {
    authorization: `Bearer ${accessToken}`,
    loginType: loginType,
  }
});

// console.log(requestData.data);

Outro.

실제로 내가 RESTful API를 어떻게 사용했는지 보면서 REST 개념을 공부해 보았다. 프로젝트 초기에는 API 문서를 보면서 서버에 요청하는 것이 어렵고 막막했는데, 프로젝트 한 달이 끝난 시점에는 문서를 보면서 요청하는 것이 신기하고 재밌게 느껴졌다. 아직도 그 감정을 잊지 못한다 ㅠㅠ

앞으로는 실무에서 실제로 어떻게 사용하는지, 사용하는 방법과 비교하며 블로깅을 하는 날이 왔으면 좋겠다.

← Previous Post Next Post →