REST API

March 4, 2024

REST API의 등장 배경

REST API의 탄생 배경은 웹 기술의 발전과 다양한 디바이스의 등장과 관련이 있다.
2000년대 초, HTTP의 주요 저자 중 한 명인 “로이 필딩”은
웹은 이미 훌륭한 기술을 갖추고 있었지만
당시 웹 설계의 우수성에도 불구하고 우수성이 제대로 활용되지 못하는 상황에 주목했고
웹의 핵심 기술인 HTTP의 장점을 극대화하면서도
확장성과 유연성을 갖춘 아키텍처의 필요성을 느껴 REST 를 제시하게 되었다.

2010년대 이후 스마트 기기가 본격적으로 보급되면서
서비스 및 애플리케이션 개발 흐름은
단순히 하나의 웹 브라우저만 지원하는 것이 아니라,
다양한 플랫폼과 디바이스에서의 접근을 요구하게 되었고
이러한 변화는 서버 프로그램이 여러 클라이언트와 통신할 수 있도록 설계되어야할 필요성을 더욱 부각시켰다.
즉 다양한 디바이스에 맞춰 새로운 서버를 만드는 것은 비효율적이었고
플랫폼에 종속되지 않고 범용적으로 사용가능한 서버 디자인을 필요로하게 되었다.

따라서 클라이언트와 서버의 역할 분담을 명확히 하고,
플랫폼 독립적인 데이터 통신을 가능하게 하는 효과적인 해결책으로 REST API 등장하게 된 것이다.

💡 2000년대 당시 웹 설계의 우수성에도 불구하고 제대로 활용되지 못한 이유는?

◾ HTTP의 의미론적 활용 부족
◾ 상태 관리의 복잡성
◾ 과도한 프로토콜 사용 (SOAP)
◾ 웹의 분산 시스템으로서의 잠재력 미활용
◾ 클라이언트의 다양성 증가에 대한 대응 부족

REST API? RESTful API?

REST(Representational State Transfer) 는

웹 아키텍처 스타일 중 하나로
REST는 기본적으로 HTTP 프로토콜을 기반으로 하며,
웹에서 자원을 효율적으로 관리하고 상호작용하기 위한 원칙과 규칙을 제공한다.
REST는 네트워크에서 통신을 구성할 때 어떤 구조로 설계할지 확인할 수 있는 지침서이고
API는 소프트웨어 간의 상호작용을 가능하게 하는 인터페이스를 의미한다.
즉, REST API는 REST 원칙을 따르는 API를 의미하며,
HTTP를 잘 사용하기 위해, URI와 HTTP메서드를 사용해서,
URL로 어떤 자원에 접근할 것인지, 메서드로 어떤 행위를 할것인지 표현하여 설계된 API를 말한다.

RESTful API 는

REST 아키텍처의 원칙을 엄격하게 준수하는 API로 의미한다.
즉 REST가 제시하는 제약 조건들을 모두 만족하는 API를 RESTful 하다고 할 수 있다.

REST의 구성

REST는 세 가지 핵심 요소로 구성된다.

자원 (Resource): URI로 식별되는 정보의 단위
행위 (Verb): HTTP 메서드로 표현되는 자원에 대한 작업
표현 (Representation): 자원의 상태를 나타내는 형식

자원 (Resource)

웹에서 접근할 수 있는 정보의 단위로, 데이터베이스의 레코드, 문서, 이미지 등 다양한 형태를 가질 수 있다. 중요한 것은 각 자원이 고유하게 식별될 수 있어야 한다.
각 자원은 URI(Uniform Resource Identifier)를 통해 고유하게 식별된다.
- /users : 모든 사용자 목록이라는 자원
- /users/123 : ID가 123인 특정 사용자라는 자원
- /products/456 : ID가 456인 특정 상품이라는 자원
- /orders/789 : ID가 789인 특정 주문이라는 자원

💡 자원의 특징

고유한 식별자: 각 자원은 고유한 URI를 가져야 한다.
서버에 존재: 자원은 서버에 저장되어 관리된다.
상태를 가짐: 자원은 특정 시점에 특정 상태를 가진다.

행위 (Verb)

자원에 대한 작업을 나타낸다. HTTP 메서드를 사용하여 이러한 작업을 표현한다.

표현 (Representation)

자원의 현재 상태를 나타내는 형식으로, 클라이언트가 자원에 대한 정보를 요청할 때 서버가 응답하는 데이터 형식이다.
자원은 JSON, XML, HTML 등 다양한 형식으로 표현될 수 있으며, 클라이언트와 서버는 어떤 형식으로 데이터를 주고받을지 합의해야 한다.

URI 란?

REST의 핵심 개념은 자원(Resource)이다.
URI(Uniform Resource Identifier)는 인터넷 상에서 특정 자원을 가리키는 식별자다.
URI는 두 가지 형태로 나뉘는데, 바로 URL(Uniform Resource Locator)과 URN(Uniform Resource Name)이다.

URI (Uniform Resource Identifier)

인터넷에 있는 자원을 어디에 있는지 자원자체를 식별하는 방법으로
인터넷 상에서 특정 자원을 가리키는 식별자(문자열)이다.
URI는 두가지 형태로 나뉘는데, 바로 URL과 URN이다.

URL (Uniform Resource Locator)

URL은 어떻게 리소스를 얻을 것이고 어디에서 가져와야하는지 명시하는 URI이다.
네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약이다.
네트워크 상에서 리소스가 위치한 정보를 나타낸다. 우리는 흔히 URL을 주소로만 알고있다.
주소에 접속하려면 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다.

💡 URL구조

scheme:[//host[:port]][/path][?query][#fragment]

1) scheme : 자원에 접근하기 위해 사용되는 프로토콜 또는 접근 방식을 나타낸다.
2) host : 자원이 호스팅 되고 있는 서버 도메인 이름 또는 IP이다.
3) port : 자원에 대한 요청을 수신하는데 사용되는 서버의 포트 번호이다.
4) path : 서버 내에서 자원의 위치를 나타낸다.
5) query : 서버에 전달하는 추가적인 매개변수(parameter)를 나타낸다.
6) fragment : 자원 내의 특정 부분을 가리키는 식별자를 나타낸다.

URN (Uniform Resource Name)

자원의 위치에 관계없이 고유한 이름을 부여하는 URI다.
URL이 리소스가 있는 위치를 지정한다면, URN은 리소스에 이름을 부여하는 것이다.
http와 같은 프로토콜을 제외하고 리소스의 name을 가리키는데 사용된다.
URN에는 리소스 접근방법과 웹 상의 위치가 표기되지 않는다.
실제 자원을 찾기 위해서는 URN을 URL로 변환하여 이용한다.

💡 URI vs URL vs URN

◾ URN은 리소스를 어떻게 접근할 것인지 명시하지 않고 경로와 리소스 자체를 특정하는 것을 목표로하는 URI이다.
◾ URL은 자원의 위치를 식별하기 때문에 통신 프로토콜를 지정하지만, URN은 자원의 위치와는 상관 없기 때문에 통신 프로토콜을 지정하지 않는다.
◾ URN은 고유한 이름으로 자원을 식별하기에 자원이 이동되어도 문제 없이 식별 가능하지만, URL은 자원이 한번 이동되면 더이상 식별할 수 없다.

REST의 제약 조건

REST는 웹에서 자원을 효율적으로 관리하고 상호작용하기 위한 제약조건을 제시하고 있다.

클라이언트-서버 구조 (Client-Server)

클라이언트와 서버는 명확하게 분리되어 서로 독립적으로 발전해야한다. 클라이언트는 사용자 인터페이스와 사용자 경험에 집중하고, 서버는 데이터 저장, 처리 및 비즈니스 로직에 집중한다.

→ 서로 간 의존성을 줄이고 효율성을 극대화시킬 수 있다.

무상태성 (Stateless)

서버는 클라이언트의 이전 요청에 대한 어떠한 상태 정보도 저장하지 않는다. 모든 요청은 필요한 모든 정보를 포함하고 있어야 하며, 서버는 각 요청을 독립적으로 처리해야한다.

→ 서버는 어떤 작업을 위해 상태정보를 기억할 필요가 없고 들어온 요청에 대해 처리만 해주면 되기 때문에 구현이 쉽고 단순해진다.

캐시 가능성 (Cacheable)

서버의 응답을 클라이언트나 중간 매개체(예: 프록시 서버)가 저장해 둘 수 있어야 한다.

→ 자주 사용하는 정보에 빠르게 접근할 수 있도록 하여 클라이언트의 성능을 향상시키고 서버의 부하를 줄일 수 있다.

균일한 인터페이스 (Uniform Interface)

자원 식별, 메시지 형식, 자기 서술적 메시지 등 일관된 인터페이스를 제공해야 한다. 어떤 기기든 쉽게 연결하고 사용할 수 있도록 인터페이스를 단순화하고 통일하는 것이다.

→ 클라이언트와 서버 간의 상호 작용을 단순화하고 시스템의 유연성을 높일 수 있다.

계층형 시스템 (Layered System)

클라이언트와 서버 사이에 여러 중간 계층을 두어 시스템의 유연성, 확장성, 보안성을 향상시켜야한다.

→ 클라이언트는 최종 목적지인 서버에 요청을 보내기만 하면되며, 중간 계층들은 각자의 역할을 수행하여 시스템의 효율성을 높일 수 있다.

(선택적) 주문형 코드 (Code-On-Demand)

선택적 제약조건 이며 서버에서 클라이언트로 코드를 전송하여 클라이언트의 기능을 동적으로 확장할 수 있도록 할 수 있다.

→ 클라이언트가 원래 가지고 있지 않은 기능을 서버에서 필요에 따라 제공하는 기능을 확장시키킬 수 있다.

Reference

DongSup Ahn