(Node.js) REST, RESTful API

호두파파·2021년 8월 1일

REST Restful node.js 노드JS

Node.js

목록 보기

13/25

RESTful하게 APU를 만들어라 ?

이런 말을 들었을때 RESTful하다는게 어떤 뜻일지가 궁금해진다.

요약하면, RESTful하다는 것은
REST한 특징을 지키는 것을 의미한다

1. REST ( Representional State Transfer)?

먼저, REST는 프로토콜이 아니다.
REST는 웹에 있는 기존 기술(GET, POST 등)과 HTTP 프로토콜을 그대로 활용하는 아키텍쳐 스타일이다.

조금 더 나아가서 웹과 관련해 존재하는 모든 자원(이미지, 동영상, DB 데이터 등)에 고유한 URI를 부여하는 자원을 정의하고 자원에 대한 주소를 지정하는 방법론이라는 측면에서

REST는 **HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 자원(Resource: URI)과 행위(Verb: HTTP Method)로 표현하여 특정한 형태로 전달하는 방식이라고도 정의할 수 있다.

정의에 사용된 자원, 행위, 형태는 REST를 이루는 구성이라고 할 수 있다.

REST는 왜 대두되었을까?

애플리케이션의 분리/통합과 다양한 클라이언트의 등장이 원인이라고 할 수 있다. 점저 서비스는 커지고 애플리케이션의 복잡도는 증가한다.

이에 따라 애플리케이션을 분리하고 통합하는 것은 중요한 이슈가 되었고, MSA와 REST가 대두되기 시작했다. 또한 모바일과 PC 및 다양한 장치의 등장에 따라 하나의 서버가 다양한 장치(여기서는 클라이언트)에 대응하기 위해 REST의 일괄된 인ㅌ페이스라는 특징이 REST를 대두하게 만들었다.

1) 구성

자원(Resource): URI라고도 한다.
서버는 Unique한 ID를 가지는 Resource(URI)를 가지고 있따.

URL과 URI의 차이
URL (Uniform Resource Local) : 인터넷 상에서 자원의 위치
URI (Uniform Resource Identifier) : 인터넷 상에서 자원을 식별하기 위한 것,
즉 , URI가 URL보다 큰 개념으로 URI는 URL을 포함한다.
행위(Verb)
HTTP Method라고 할 수 있따.
일반적으로 GET, POST, PUT, PATCH, DELETE 등이 있다.
(1) GET: 데이터 조회 (READ)
(2) POST: 데이터 생성 (CREATE)
(3) PUT: 데이터 수정(UPDATE)
(4) PATCH: 데이터의 부분적인 수정
(5) DELETE: 데이터 삭제
표현(Representations)
클라이언트와 서버가 데이터를 주고받는 형태이며, JSON, XML, TEXT, RS 등이 있다. 일반적으로 JSON을 가장 많이 쓰는 추세이다.

특징

❗️ RESTful API가 되기 위해서는 아래의 특징들이 지켜져야 한다.

Uniform Interface(균일한 or 일관된 인터페이스)
이 특징은 RESTful 시스템 설계의 기본이다.
아키텍쳐를 단순화하고 분리해, 각 부분이 독립적으로 발전할 수 있도록 하는데, 이때 Uniform Interface의 네가지 제약은 아래와 같다.
(1) Resource identification in requests
(2) Resource manipulation through representations
(3) Self-descriptive messages (자체적인 설명이 되는 메시지)
각 메시지는 메시지 처리 방법을 설명하기에 충분한 정보가 포함되어 있어야 한다.

(4) Hypermedia as the engine of application state
Stateless(무상태성)
상태정보를 따로 관리하지 않고 단순히 API 서버로 들어오는 요청만을 처리하면 된다.
이는 서비스의 자유도가 높아지게 해주며, API 서버에 불필요한 정보를 관리하지 않게 되므로 구현에도 용이하다.
Cacheable(캐시가능)
HTTP 기존의 웹 표준을 사용하므로 HTTP 프로토콜 기반의 로드벨런서(mod_proxy), SLL, 캐싱 기능을 적용가능.
Client-Server Architecture(서버- 클라이언트 구조)
REST API에서 자원을 가지고 있는 쪽이 서버, 자원을 요청하는 쪽이 클라이언트에 해당한다. 일반적으로 서버는 API를 제공하고, 클라이언트는 그 정보를 사용하는 다른 역할(사용자 인증, 세션 관리, 로그인 정보 관리 등)을 함으로써 역할의 구분을 통해 의존성을 줄인다.
Layered System(계층 구조)
클라이언트는 서버와 직접 통신하는지, 서버 앞의 중간 서버와 통신하는지 알 수 없다.
'클라이언트 요청 > Rest API(데이터 조회)처럼 사용되는 것처럼 보일 수 있다. 하지만, '클라이언트 요청 > Rest API(프록시 서버> 로드 벨런싱 > 암호화 > 데이터조회)'처럼 보다 더 많은 다양한 계층을 거칠수도 있다.

장점

잘 만들어진 RESTful API 메시지를 보는 것으로 메시지의 의도를 파악할 수 있다.
Steteless를 통해 클라이언트와 서바가 각자의 역할에 충실할 수 있다.

단점

제한적인 HTTP method로 인해 여러가지 기능을 구현하는 데는 제약이 발생할 수 있다.
또한, 가장 큰 단점으로 표준이 존재하지 않는다는 것이다.
(공식대로 만들어라라는 표준이 존재하지 않기 때문에, RESTful API를 사용하는 각 조직의 '약속'에 따라 만들어지게 된다.)