REST, REST API

우리는 개발을 할 때, 수도 없이 API라는 개념을 접한다.

그런데 우리는 이제 단순 API가 아니라 REST 혹은 RESTFUL한 API를 지향해야한다고 말한다. (API에 대해 잘 모르겠다면, API 링크(tistory.com)를 참고하자)

대체 왜 REST를 지향하는 것일까?

현대에 안드로이드폰, 아이폰와 같은 모바일 디바이스와 브라우저 등 다양한 클라이언트들이 등장함에 따라 다양한 클라이언트들에 대응하기 위한 전략이 필요했다.

또한, 애플리케이션이 점점 더 복잡해지면서 애플리케이션을 어떻게 효율적으로 분리하고 통합하느냐가 큰 쟁점 중 하나로 대두되었다.

그에 따라, 이에 대한 대안을 마련해줄 수 있는 REST에 관심을 가지게 되었다.

그렇다면 REST, RESTFUL는 무엇일까?

REST란

REST는 Representational State Transfer의 약자이다.

REST는 로이필딩에 의해 처음으로 용어가 사용되어졌고, www(월드와이드웹)와 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍쳐 스타일이다.

REST는 이름에서 살펴볼 수 있듯이, 자원의 이름(자원의 표현[Representation])으로 구분하여 자원의 정보(상태[State])를 주고 받는(송수신 [Transfer]) 모든 것을 의미한다.

구체적으로 알기 앞서, Representation, State, Transfer 각각이 의미하는 바를 간단하게 살펴보자.

​

자원의 표현(Representation)이란?

• 자원 - 해당 소프트웨어에 존재하고 관리되어지는 모든 것 (e.g. 데이터, 이미지, 동영상)
• 자원의 표현 - 자원을 출력하기 위한 이름 (e.g. students(DB에 저장된 학생 정보), employees(DB에 저장된 임직원 정보))

자원의 상태(State)란?

• 요청되어지고 전달되는 데이터(정보)
• JSON, XML 등이 일반적이다.

전달(Transfer)이란?

• 시기적절하게 데이터를 전송한다.

즉, REST는 간단하게 자원의 상태에 의한 상태 전달이라는 아키텍쳐 형태이다.

여기서 말하는 아키텍처는 리소스 지향 아키텍처(ROA) 설계를 의미한다.

이는 설계의 중심에 리소스가 있고 HTTP에서 제공하는 메소드를 통해 해당 자원에 대한 CRUD를 적용한다는 것을 내포하고 있다.

REST 구성 요소

REST는 크게 보자면 3가지로 이루어져 있다고 볼 수 있다.

1. Resource(자원) - 자원을 표현하는 URI
   • 서버에 존재하는 모든 자원에는 고유한 식별자가 존재한다.
   • 자원을 식별하는 이 식별자는 "/students/{id}"와 같은 HTTP URI이다.
   • 클라이언트는 URI를 활용해서 자원을 지정하여 서버에 요청을 하면 서버는 그에 해당하는 자원을 내어준다.
2. Verb(행위) - CRUD를 진행할 수 있는 HTTP Method
   • 자원에 대한 행위를 처리할 수 있다.
   • Create(POST) - 자원의 생성
   • Read(GET) - 자원의 조회
   • UPDATE(PUT) - 자원의 수정
   • DELETE(DELETE) - 자원의 삭제
3. Representations(표현) - 자원을 제공하는 형태(JSON, XML 등)
   • 클라이언트가 URI를 활용해서 자원을 지정하여 서버에 요청하는 그에 해당하는 자원을 내어준다.
   • 자원은 JSON, XML, TEXT 등 다양한 형태로 주어질 수 있다.
   • 일반적으로 JSON, XML이 사용된다.

REST 특징

1. Stateless(무상태)
   • REST는 무상태성 성격을 가지기에 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
   • 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않으며 단순 요청을 처리하면 된다.
   • 서비스의 처리에 일관성이 부여되고 자유도가 높아진다.
2. Client-Server(클라이언트-서버 구조)
   • 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보 등)을 직접 관리한다.
   • 서버는 리소스를 가지고 있고 API를 제공한다.
   • 각각의 역할이 확실히 구분되어 개발해야 할 내용이 명확해지고 서로간의 의존성이 줄어든다.
3. Uniform Interface(인터페이스 일관성)
   • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다.
   • 아키텍처를 단순화하고 분리해 각 부분을 독립적으로 발전 시킬 수 있다.
4. Cacheable(캐시 처리 가능)
   • REST의 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능하다는 것이다.
   • 그에 따라, HTTP가 가진 캐싱 기능을 사용할 수 있다.
   • 조회 등 다양한 부분에서 캐싱하는 것은 용량이나 성능 면에서 이점을 준다.
   • 대량의 요청을 효율적으로 처리하기 위해 캐시를 사용한다.
5. Layerd System(계층형 시스템)
   • 서버는 다층 계층으로 구성될 수 있다.
   • PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
   • 즉, 비지니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증, 암호화, 로드밸런싱 등의 계층을 추가해 구조상의 유연성 제공할 수 있다.
6. Self-Descriptiveness
   • REST의 큰 특징 중 하나는 REST API 메세지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다는 것이다.
   • REST는 동사(Method) + 명사(URI) 형태로 이루어져 있어 어떤 메서드에 무슨 행위를 하는지 쉽게 알 수 있다.

REST API

우리는 이러한 REST에서의 강점을 이해했고 상당한 메리트가 있다는 것을 알 수 있었다.

그렇다면 RESTful한 설계는 어떻게 이루어져야할까?

이를 위한 가장 중요하고 기본적인 규칙이 존재하는데 우리는 다음 두 가지를 꼭 숙지해야한다.

REST API 설계 규칙

첫 번째, HTTP URI를 통해 자원을 표현해야한다는 것이다.

• 자원의 표현은 동사보다는 명사를, 대문자보다는 소문자의 사용을 지향해야한다.
• 자원이 Collection이라면 복수 명사를 사용한다.

두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다는 것이다.

• URI에 HTTP Method가 포함되면 안된다.
• 경로 부분 중 유동적인 부분은 유일한 값(식별자)로 대체한다. (e.g. /students/{id})

REST API 설계 주의점

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
3. 하이픈(-)은 URI 가독성을 높이는데 사용
4. 밑줄(_)은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
6. 파일확장자는 URI에 포함하지 않는다.

REST API 설계 예시

참조문헌

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

https://tech.devgear.co.kr/delphi_news/433404)

https://meetup.toast.com/posts/92

https://brainbackdoor.tistory.com/53

https://www.slipp.net/wiki/pages/viewpage.action?pageId=12878219