REST API

REST API, RESTful API에 대해서 알아보려고 한다. 평소에 RESTful한 API로 구성한다, 만든다라는 것을 많이 접했는데 정확히 어떤 것을 의미하는지 알아보았다.

 

REST

REST는 Representational State Tranfer의 약자이다.

 

자원(리소스)를 자원의 표현(또는 이름)으로 구분하여 해당 자원의 상태를 주고 받는 것을 의미한다. 즉, 모든 자원에 고유한 URI을 부여해 활용하는 것으로 자원의 표현에 의한 상태 전달로 말할 수 있다.

 

RESTful API는 이러한 REST 특징을 지켜서 API를 제공하는 것을 의미한다.

 

어플리케이션의 복잡도가 증가하면서 어떻게 어플리케이션을 분리하고 통합하는지가 주요 이슈가 되었고, 최근에는 SPA를 이용하여 클라이언트를 구현하기 때문에 클라이언트와 서버를 분리하여 클라이언트 로직을 분명히 한다. 그리고 모바일과 같은 다양한 클라이언트가 등장하여 다양한 디바이스에 대응하기 위해 REST의 필요성이 증대되었다. 

 

 

REST의 구체적인 개념

REST는 다음의 3가지로 구성으로 이루어져 있다.

• 자원 (Resource) - URI
• 행위 (Verb) - HTTP method
• 표현 (Representations)

즉, HTTP URI를 통해 자원을 명시하고, HTTP method를 통해 해당 자원에 대한 CRUD를 적용하는 것을 말한다. 

 

자원이란 해당 소프트웨어가 관리하는 모든 데이터를 말한다. (ex 문서, 그림, 데이터, 해당 소프트웨어 자체 등)

 

모든 자원에 고유한 ID가 존재하고 그 자원을 표현한다. 예를들어 학생 정보가 자원일 경우, 'students' 등으로 표현하는 것을 말한다. 이렇게 자원에 고유한 HTTP URI를 부여하고 HTTP method(GET, POST, PUT, DELETE)를 이용하여 해당 자원을 처리하는 것이다.

 

ex.

/students GET

/users/5 GET

 

자원의 상태(정보)는 데이터가 요청되어지는 시점에서 전달되고, JSON을 이용하여 데이터를 주고받는 것이 일반적이다.

 

 

REST의 특징

1. 클라이언트 - 서버 구조

자원을 관리하는 쪽은 서버, 자원을 요쳥하는 쪽은 클라이언트로 분리하여 서버에서는 API를 제공하고, 비지니스 로직 처리 및 저장을 책임진다. 클라이언트는 사용자 인증이나 context를 직접 관리하고 책임진다. 

 

이렇게 각각의 역할이 확실히 구분됨으로써, 서로간 의존성이 줄어들고 개발해야 할 내용이 명확해진다.

 

2. Stateless (무상태)

HTTP의 특성을 이용하기 때문에 마찬가지로 무상태성을 갖고 이는 서버에서 어떤 작업을 할 때 상태정보를 기억할 필요 없이 들어온 요청만 처리하면 되기 때문에 구현이 쉬워지고 단순해진다.

 

3. 자체 표현 구조

동사 (method) + 명사 (URI)로 이루어져 있기 때문에 REST API 메시지만 보고도 어떠한 행위를 하는지 쉽게 이해 할 수 있고, JSON 메시지 포멧을 사용하기 때문에 직관적인 이해가 가능하다.

 

4. 유니폼 인터페이스

HTTP 표준에만 따른다면, 어떤 플랫폼이나 특정 언어에 종속되지않고 모든 플랫폼에 일관되게 사용이 가능하고 URI로 지정한 자원에 대한 조작이 가능한 것을 의미한다.

 

5. 계층화

클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버 등 중간 매체를 사용할 때 자유도가 높고 구조상의 유연성이 있다.

 

6. 캐치 처리 가능

HTTP 표준을 따르기 때문에 웹에서 사용하는 인프라를 그대로 사용할 수 있다.

 

 

 

REST API

REST API는 위의 REST를 기반으로 서비스 API를 구현한 것이다.

 

REST API의 설계하는 법은 다음과 같다.

 

1. URI는 정보의 자원을 표현한다. 말그대로 정보의 자원을 표현하기 때문에 몇가지 규칙이 있다.

- 소문자를 사용한다

- 하이픈 (-) 을 사용한다. 불가피하게 긴 URI를 사용할 경우, 하이픈으로 가독성을 높이는데 사용한다.

- 확장자를 사용하지 않는다.

- 밑줄 (_) 은 사용하지 않는다.

- 슬래시는 계층 관계를 나타내는데 사용하고, 마지막 문자로 슬래시를 포함하지 않는다.

 

2. 자원에 대한 행위는 HTTP method로 표현한다.

- GET : 해당 자원을 조회

- POST : 해당 자원을 생성

- PUT : 해당 자원 수정

- DELETE : 해당 자원 삭제

 

Ex. 

POST /posts/update/:id  (X)    -> PUT /posts/:id  (O)

 

 

RESTful

RESTful은 REST라는 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해서 사용하는 용어로 REST API를 제공하는 웹 서비스를 RESTful 하다고 할 수 있다. 즉, REST를 REST하게 쓰기위한 방법으로 REST 원리를 따르는 시스템을 RESTful하다고 표현하는 것이다.

 

RESTful의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것으로 근본적인 목적은 성능의 향상보다는 일관적인 컨벤션으로 API의 이해와 호환성을 높여주는 것이다.

 

예를들어 CRUD 기능을 모두 POST로만 처리하는 API라던지, URI에 자원, id이외에 정보가 들어가는 경우 등은 RESTful하지 못하다고 할 수 있다.

 

---

REST, REST API, RESTful이 무슨 개념이고 어떤 의미를 가지고 있는지 알수 있었다.

 

REST에 대해서 공부하고 나니까 지금까지 내가 구현했던 것들이 알고보니 전부 REST의 개념을 사용하고 있었다는 것을 깨달았다.  REST라는 용어와 개념을 모른체로 RESTful(?) 하게 구현하고 있었다.

 

서버와 클라이언트로 나누어서 프로젝트를 했던 방식이나, URI를 통해 자원을 명시하고 HTTP method를 통해 자원을 조작했던 것, HTTP 프로토콜을 이용했던 것 등 전부 REST의 개념이었던 것이다. 뿐만 아니라 리액트 네이티브 프로젝트도 모바일 이지만 알고보니 REST의 개념으로 개발했던 것이었다. 물론 위의 RESTful의 개념처럼 완전히 RESTful하다고는 할 수 없다.

 

이제 REST의 개념을 알았으니 앞으로의 프로젝트는 좀 더 체계적이고 RESTful한 프로젝트가 되도록 할 수 있을 것 같다.

 

아래는 참고한 레퍼런스입니다.

 

 

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://brainbackdoor.tistory.com/53

https://velog.io/@wlsdud2194/HTTP-REST-API-%EB%9E%80