그래서 RESTful 하다는 게 뭔데요?

willy4202·2022년 7월 27일
0

이력서 경험을 정리하던 도중, RESTful한 API 구성을 할 수 있다는 경험을 적어놓은 것을 볼 수 있었습니다. 어떤 방법을 활용해야 RESTful한 걸까요? 이번 시간에는 REST에 대해서 알아보도록 합시다.

REST

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. - 위키백과

REST는Representational State Transfer 의 약자입니다. 자원을 이름으로 구분하여 해당 자원의 상태나 정보를 주고 받는 모든 것을 의미합니다.

더 세세하게 말하자면, HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것 입니다.

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용할 수 있기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일입니다.

즉, REST는 어떤 기술이나 특정한 장치라고 보기보단, 정보 통신을 주고받는 방법론적 개념이라 볼 수 있습니다.


REST 구성요소

1. 자원(resource) - URI

  • 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재합니다.
  • 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI 입니다.

2. 행위(verb) - method

  • HTTP 프로토콜은 GET, POST, PUT, PATCH, DELETE를 제공합니다.

3. 표현(representation of resource)

  • Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있습니다.
  • JSON, XML을 통해 데이터를 주고 받는 것이 일반적입니다.

특징

1. server-Client

  • 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client가 됩니다.
  • REST Serever는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임집니다.
    Client는 사용자 인증이나 context( 세션, 로그인 정보 ) 등을 직접 관리하고 책임집니다.
    역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄입니다.

2. Stateless

  • HTTP 프로토콜은 Stateless Protocol이므로 REST 역시 무상태성을 갖습니다.
  • Client의 context를 Server에 저장하지 않습니다.
  • 즉, 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해집니다.
  • Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.
  • 각 API 서버는 Client의 요청만을 단순 처리합니다.
  • 즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안됩니다. ( DB에 의해 바뀌는 것은 허용 )
  • Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아집니다.

3. Cacheable

  • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있습니다.
  • 대량의 요청을 효율적으로 처리할 수 있습니다.

4. Layered System

  • Client는 REST API Server만 호출합니다.
  • REST Server는 다중 계층으로 구성될 수 있습니다.

5. Uniform interface

  • URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미합니다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupling(느슨한 결함) 형태를 갖습니다. 

6. Self-Descriptivness

  • 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있습니다.

장점

이런 REST 개념을 잘 활용할 수 있다면 여러 장점이 있습니다.

  • Hypermedia API의 기본을 충실히 지키면서 범용성을 보장합니다.
  • REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있습니다.
  • 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화합니다.
  • 서버와 클라이언트의 역할을 명확하게 분리합니다.

RESTful

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다. ‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있습니다.

그래서 면접에서 어떻게 써먹죠?

RESTful은 REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 합니다. 즉, REST의 원리를 잘 따르는 시스템을 RESTful이란 용어로 지칭됩니다.

RESTful한 API를 사용하거나 구축할 수 있다고 말할 수 있으려면, 구체적인 경험이 필요합니다. 본인이 만든 프로젝트에서 찾으면 가장 좋습니다. 하지만 더 나아가서 이러한 방법을 기존에 자주 사용하거나 접속하던 서비스에서 찾아보거나 뒤져보는 것도 좋은 방법이라 생각됩니다.

예를 들어, 무신사를 봅시다.

처음엔 앱이라는 형태의 주소창을 볼 수 있습니다. 여기서 카테고리를 누르면 새로운 정보를 받아오게 되는데, 여기서 어떤 데이터를 취득하는지 확인할 수 있습니다.

카테고리 리스트를 들어갔을때 입니다.

지금은 특정한 프로덕트를 선택해서 디테일 창을 볼 수 있습니다.
특정한 고유 id번호가 붙는 것을 확인할 수 있고, product라는 곳에서 Id값을 바탕으로 다른 정보를 뿌려주고 있습니다.


이렇게 RESTful API는 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로. 만약, 성능이 중요한 상황이라면 굳이 RESTful 한 API를 구현할 필요는 없습니다.

즉, URI는 정보의 자원만 표현하며 행위는 메서드에 명시하는 것으로 RESTful하게 구현할 수 있습니다.

profile
같은 문제에 헤매지 않기 위해 기록합니다.

0개의 댓글