장정우님이 지음, [스프링부트 핵심가이드 :: 스프링 부트를 활용한 애플리케이션 개발 실무] 책을 읽고 정리한 필기입니다.📢

REST API

REST API는 대중적으로 가장 많이 사용되는 애플리케이션 인터페이스이다. 이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.

REST 란?

REST란 ‘Representational State Transfer’의 약자로, 월드 와이드 웹(WWW)과 같은 분상 하이퍼미디어 시스템 아키텍처의 한 형식이다. 주고받는 자원(Resource)에 이름을 규정하고 URI에 명시해서 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 해당 자원의 상태를 주고받는 것을 의미한다.

REST API란?

먼저 API는 ‘Application Programming Interface’의 약자로, 애플리케이션에서 제공하는 인터페이스를 의미한다. API를 통해 서버 또는 프로그램 사이를 연결할 수 있다. 즉 REST API 는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스라고 볼 수 있다. REST 아키텍처를 구현하는 웹 서비스를 ‘RESTful하다’라고 표현한다.

REST의 특징

REST에는 다음과 같은 특징이 있다.

유니폼 인터페이스

유니폼 인터페이스란 ‘일관된 인터페이스’를 의미한다. 즉, REST 서버는 HTTP 표준 전송 규약을 따르기 때문에 어떤 프로그래밍 언어로 만들어졌느냐와 상관없이 플랫폼 및 기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다는 것을 의미한다.

무상태성

REST는 ‘무상태성(stateless)’이라는 특징을 가진다. 무상태성이란 서버에 상태 정보를 따로 보관하거나 관리하지 않는다는 의미다. 서버는 클라이언트가 보낸 요청에 대해 세션이나 쿠키 정보를 별도로 보관하지 않는다. 그렇게 때문에 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리한다. 이렇게 구성된 서비스는 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순하다.

캐시 가능성

REST는 HTTP 표준을 그래도 사용하므로 HTTP의 캐싱 기능을 적용할 수 있다. 이 기능을 이용하기 위해서는 응답과 요청이 모두 캐싱 가능한지(Cacheable) 명시가 필요하며 ,캐싱이 가능한 경우 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용한다. 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효유율적이며 사용자 입장에서는 성능이 개선된다.

레이어 시스템

REST 서버는 네트워크 상의 여러 계층으로 구성될 수 있다.(Layered System). 그러나 서버의 복잡도와 관계 없이 클라이언트는 서버와 연결된 포인트만 알면 된다.

클라이언트-서버 아키텍처

REST 서버는 API를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다. 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.

REST의 URI 설계 규칙

REST API를 설계하는 데는 다음과 같은 몇 가지 규칙이 있다.

URL 규칙

URI의 마지막에서는 ‘/’를 포함하지 않는다.
- 옳은 예) http://localhost.com/product
- 잘못된 예) http://localhost.com/product/
언더바(_)는 사용하지 않는다. 대신 하이픈(-)을 이용한다.
- 하이픈은 리소스의 이름이 길어지면 사용한다.
- 옳은 예) http://localhost.com/provider-company-name
- 잘못된 예) http://localhost.com/provider_compaty_name
URL에는 행위(동사)가 아닌 결과(명사)를 포함한다.
- 옳은 예) http://localhost.com/product/123
- 잘못된 예) http://localhost.com/delete-product/123
- 행위는 HTTP 메서드로 표현할 수 있어야 한다.
URI는 소문자로 작성해야 한다.
- URI 리소스 경로에는 대문자 사용할 피하는 것이 좋다.
- 일부 웹 서버의 운영체제는 리소스 경로 부분이 대소문자를 다른 문자로 인식하기 때문이다. 이러한 이유로 RFC3986은 URI 문법 형식을 정의하고 있는데, 호스트의 구성요소를 제외하고 URI의 대소문자를 구분해서 정의하고 있다.
파일의 확장자는 URI에 포함하지 않는다.
- HTTP에서 제공하는 Accept 헤더를 사용하는 것이 좋다.

Daejoon Cho