REST API 란? REST API 와 Restful

이현지·2021년 3월 14일

REST API? Restful? API는 아는데 REST API는 뭐지..?
내가 처음 REST API를 접했을 때 든 생각이었다.
그 때 이해가 잘 안되서 나중에 꼭 정리해봐야겠다고 생각해서 포스팅을 하게 됐다.

REST API 란?

쉽게 말해 REST 아키텍쳐를 따르는 API 라고 할 수 있다.
그렇다면 REST 아키텍쳐는 무엇일까?

REST(Representational State Transfer) 란?

HTTP를 이용해 통신하는 네트워크 상에서 정한 약속이며,
인터넷과 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식이다.
웹이 깨지는 현상 없이 어떻게 HTTP를 개선할지에 대한 것이 만든 계기이다.

Representational : 자원을 대표하는 식별자
State Transfer : 자원의 상태를 전송하는 방법

즉, 자원을 대표하는 식별자와 자원의 상태를 전송하는 방법을 포함하고 있어야 한다.
자원은 URI를 나타내고, 전송하는 방법은 HTTP Method를 나타낸다.

대표적인 HTTP Method


Create	POST
Read	GET
Update	PUT
Delete	DELETE

Restful 이란?

REST 제약조건의 집합을 모두 지키는 것을 Restful 하다고 한다.

REST 제약조건의 집합

1. Client / Server

REST API에서 자원을 가지고 있는 쪽은 서버, 자원을 요청하는 쪽은 클라이언트이다.
서버는 API를 제공하고, 클라이언트는 사용자 인증, Context(세션,쿠키)등을 직접 관리하여,
서버와 클라이언트의 역할을 확실히 구분시킴으로써 서로 간의 의존성을 약하게 한다.

2. Stateless

클라이언트의 Context가 서버에 저장되면 안된다.
서버는 각각의 요청을 별개의 것으로 인식해야하기 때문이다.
REST API는 세션정보나 쿠키정보를 활용하여, 상태정보를 저장 및 관리하지 않는다.
이전 요청이 다음 요청과 연관되어서는 안된다.
Stateless(무상태성)은 서버의 처리방식에 일관성을 부여하고, 서버의 부담을 줄여준다.

3. Cacheable

REST API도 HTTP 프로토콜에서 사용하는 Last-Modifid Tag 또는 E-Tag를 이용하여
캐싱을 구현할 수 있고, 캐싱을 활용하여 대량의 요청을 효율적으로 처리할 수 있다.

4. Layered System

REST API 서버는 다중 계층으로 구성될 수 있다.
보안, 로드밸런싱, 암호화등을 위해 계층을 추가 하여 구조를 변경할 수 있다.
또한 Proxy나 Gateway와 같은 네트워크 기반의 중간매체를 사용할 수 있게 해준다.
그래서 클라이언트는 서버와 직접 통신하는지, 중간서버와 통신하는지 알 수 없다.

5. Code on demand(optional)

코드를 클라이언트한테 보내서 실행할 수 있어야 한다.
ex) javascript

6. Uniform Interface

자원에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍쳐 스타일
REST API는 HTTP를 사용하는 모든 플랫폼에서 요청 가능하다.

Uniform Inteface 에는 4가지 제약 조건이 있다.

identification of resources
자원은 유일하게 식별할 수 있어야한다.
manipulation of resources through representations
HTTP Method로 표현해야한다.
예를 들어 수정한다고 하면 PUT/members/1
self-descriptive messages
스스로 설명할 수 있는 메시지
메시지를 통해 어떤 언어로 무엇을 요청하는지 알 수 있어야 한다.

self-descriptive 하지 않은 경우

GET/members/1

self-descriptive 한 경우
이 URI가 어디로 향하는지 목적지를 적어주는 것이다.

GET/members/1
Host: hyun-jii.github.io

hypermedia as the engine of application state (HATEOAS)
하이퍼링크를 통해서 상태가 전이(HATEOAS) 되어야 한다.
예를 들어 HTML의 경우 a태그를 통해서 상태가 전이 된다. 이는 HATEOAS를 지킨 것이라고 할 수 있다.
그러나 JSON의 경우는 a태그와 같은 것이 없으므로 Media type을 정의하거나,
명세를 작성하여 Link 헤더에 링크하는 법, data로 하이퍼링크를 표현하는 법이 있다.

REST를 알아보았으니 REST의 자원을 나타내는 URI에 대해서도 알아보자

URI와 URL

URL은 Uniform Resource Locator로 인터넷 상 자원의 위치를 나타내고,
URI는 Uniform Resource Identifier로 인터넷 상의 자원을 식별하기 위한 문자열의 구성이다.
그렇다면 우리가 알고있는 URL? URI? 정확히 무엇이 다른걸까??
우선 URI는 URL을 포괄하는 개념이다. URI가 더 상위개념이다.
예를 들어 https://hyun-jii.github.io 는 자원의 위치와 자원을 식별할 수 있으므로
URL 이면서 URI 이다.
그리고 https://hyun-jii.github.io/posts/first.html 는
hyun-jii.github.io 하위에 posts 디렉토리가 있고, 디렉토리 아래
first.html 이라는 자원의 위치를 나타내고, 식별하므로 URL 이면서 URI 이다.
마지막으로 https://hyun-jii.github.io/157 은 뒤에 157은 자원의 위치를 나타내지 않고,
자원을 식별만 하므로 URI이다.

URI 설계 시 주의할 점

슬래시 구분자(/)는 계층 관계를 나타낼 때 사용한다.
ex) https://hyun-jii.github.io/posts/12
URI 마지막은 슬래시(/)를 포함하지 않는다.
하이픈은 URI 가독성을 높일 떄 사용한다.
밑줄()는 URI에 사용하지 않는다. 밑줄()은 가독성이 떨어지고,
밑줄에 의해 문자가 가려진다.
URI 경로에는 소문자를 사용한다.
파일 확장자를 URI에 포함시키지 않는다.
HTTP Accept Header를 사용한다.
ex) Accept : text/html

현재 대부분이 REST API라고 불리는 것이 완벽한 REST API가 아니라고 한다.
다른 제약조건들은 잘 지켜지고 있으나, Uniform Interface의
self-descriptive와 HATEOAS가 잘 지켜지고 있지 않다.
아무래도 시간과 구현의 어려움때문인 것 같다.