CS/네트워크

HTTP와 RESTful API, REST란?

개발자 May 2024. 8. 6. 15:42

REST는 웹 서비스의 아키텍처 스타일 중 하나입니다. REST의 주요 원칙으로는 무상태성, 캐시 가능, 클라이언트-서버 구조, 계층형 구조, 인터페이스 동일성, 그리고 선택적으로 코드 온 디맨드가 있습니다. 이러한 원칙을 지켜 설계된 시스템이나 API를 RESTful 하다고 표현할 수 있습니다.

REST는 자원, 행위, 표현으로 구성되며, 한마디로 URI로 표현된 자원에 대한 연산을 수행하고, 상태를 주고받는 아키텍처 스타일입니다.

REST의 설계 원칙은 HTTP의 메서드(GET, POST, PUT, DELETE 등)와 헤더, 상태 코드와 자연스럽게 어우러져, 대부분의 RESTful 시스템은 HTTP 프로토콜을 사용하여 동작합니다. REST는 HTTP의 사용을 유연하고 확장성 있게 사용할 수 있도록 설계 원칙을 제시하여, 웹 서비스의 효율성과 확장성을 높입니다.

REST(Representational State Transfer, 표현형 상태 전송)

  • 정의: REST는 웹 서비스의 아키텍처 스타일을 정의하는 개념이다. 로이 필딩(Roy Fielding)이 그의 박사학위 논문에서 소개한 개념으로, 네트워크 시스템, 특히 웹에서 클라이언트와 서버 간의 통신을 단순하고 확장 가능하며 유지 보수하기 쉽게 만드는 원칙을 제시한다.
  • Representational: 인터넷상의 자원을 URI(Uniform Resource Identifier)로 나타낼 수 있음을 의미한다. 클라이언트는 URI로 표현된 자원을 HTTP 메서드를 이용해 CRUD 연산을 할 수 있다.
  • State Transfer: 요청받은 자원의 상태를 전달하는 것을 의미한다. (자원의 상태를 주고받는다)

⇒ 자원을 명시해 연산을 수행하고 자원의 상태를 주고받는 것

위 정의는 아래 6가지 주요 원칙 중 '인터페이스의 통일성'으로부터 비롯된 자원, 행위, 표현 부분을 살펴보면 이해가 가능하다.

REST의 6가지 주요 원칙

  1. 클라이언트-서버 구조: 클라이언트와 서버가 각자의 역할에 맞게 구성되어, 서로 독립적으로 개발될 수 있도록 한다. 요청-응답 구조로 통신한다.
  2. 무상태성(Stateless): 각 요청은 다른 요청과 독립적이며, 서버는 클라이언트의 상태를 저장하지 않는다. 즉, 요청은 필요한 모든 정보를 자체적으로 포함해야 한다.
  3. 캐시 가능 (Cacheable): 웹 응답은 캐시 가능해야 한다. 이를 통해 클라이언트의 많은 요청으로부터 서버 부하를 줄여 주고, 클라이언트는 비교적 빠른 응답을 받을 수 있다.
  4. 계층형 구조 (Layered System): 아키텍처는 여러 계층으로 구성될 수 있으며, 각 계층은 서로의 역할을 숨기고 독립적으로 동작할 수 있다. 그렇기에 보안, 암호화와 같은 계층을 추가해 서버에 대한 기능을 유연하게 확장할 수 있다.
  5. 인터페이스의 통일성 (Uniform Interface): 모든 API가 일관된 인터페이스를 통해 상호작용하도록 설계되어야 한다. 이를 통해 단순성과 일관성을 유지할 수 있다.
  6. 코드 온 디맨드 (Code on Demand) (선택적): 서버는 클라이언트에게 코드를 전송하여 실행할 수 있다. 클라이언트가 서버에서 받은 코드를 실행하므로, 악의적인 코드가 전송될 위험이 있다. 현대에는 동적 웹 콘텐츠를 구현할 수 있는 웹 기술의 발달로, 필요성 또한 사라졌다.
@RestController
public class ScriptController {

    @GetMapping("/dynamic-script")
    public String getScript() {
        return "console.log('This is a dynamic script from the server');";
    }
}

REST의 구성 - 자원, 행위, 표현의 개념

REST의 원칙을 구체적으로 구현하기 위해 자원, 행위, 표현이라는 개념이 등장했다. 이 개념들은 RESTful API의 설계에서 중요한 역할을 하며, REST의 원칙을 실질적으로 적용하는 방법을 제공한다.

자원 (Resource)

  • 정의: RESTful 아키텍처에서 모든 데이터와 개체는 자원으로 취급된다. 자원은 URI로 식별된다.
  • 역할: 자원은 API에서 관리하고자 하는 모든 데이터와 개체를 표현한다. 예를 들어, 사용자는 /users라는 자원으로 표현될 수 있다.

행위 (Action)

  • 정의: 자원에 대한 작업을 나타내며, HTTP 메서드를 사용하여 표현된다.
  • 역할: 자원에 대한 CRUD(Create, Read, Update, Delete) 작업을 정의한다. 예를 들어, GET /users는 사용자 목록을 조회하는 행위이다.

표현 (Representation)

  • 정의: 자원의 상태를 전달하는 데이터 형식이다. 일반적으로 JSON, XML, HTML 등의 형식으로 제공된다.
  • 연관된 원칙: 무상태성
  • 역할: 표현은 클라이언트와 서버 간의 데이터 전송 형식으로, 요청과 응답에서 자원의 상태를 나타낸다. 클라이언트는 표현을 통해 서버의 자원을 요청하거나 상태를 변경할 수 있다.

왜 자원, 행위, 표현이 중요한가?

  1. 자원의 중심적 역할: REST는 자원 중심적(Resource-Oriented) 아키텍처이다. 모든 데이터는 자원으로 정의되고 URI를 통해 접근된다. 이는 클라이언트와 서버 간의 명확한 데이터 흐름을 가능하게 한다.
  2. 일관된 행위 정의: HTTP 메서드는 자원에 대한 표준화된 행위를 제공하여, 클라이언트가 API와 상호작용하는 방식을 일관되게 한다. 이는 REST의 인터페이스 통일성을 보장하는 데 기여한다.

RESTful API

  • 정의: RESTful은 REST 아키텍처 스타일을 따르는 서비스 또는 API를 설명하는 용어이다. 즉, REST의 원칙과 제약을 준수하여 설계된 웹 서비스나 API를 가리킨다.
  • RESTful API의 특징:
    • 리소스 기반 구조: URL은 리소스를 나타내며, HTTP 메서드를 사용하여 리소스에 대한 작업을 수행한다. 예를 들어, /users는 사용자 리소스를 나타내고, GET /users는 모든 사용자를 가져오는 작업을 수행한다.
    • HTTP 메서드 사용: RESTful API는 일반적으로 HTTP 메서드를 사용하여 작업을 수행한다. GET은 리소스를 조회하고, POST는 리소스를 생성하며, PUT은 리소스를 업데이트하고, DELETE는 리소스를 삭제한다.
    • 상태 코드: HTTP 상태 코드를 사용하여 요청의 결과를 나타낸다. 예를 들어, 200 OK는 요청이 성공했음을 나타내고, 404 Not Found는 리소스를 찾을 수 없음을 나타낸다.
    • 데이터 포맷: JSON 또는 XML과 같은 표준 포맷을 사용하여 데이터를 주고받는다.

REST와 RESTful의 차이

  • REST: 아키텍처 스타일과 원칙을 정의하는 개념이다. 특정한 구현 방법이나 기술에 얽매이지 않고, 설계의 방향성을 제공한다.
  • RESTful: REST 원칙을 구체적으로 구현한 서비스나 API를 가리킨다. RESTful 서비스는 REST의 제약과 원칙을 실질적으로 적용하여 설계된다.

REST와 HTTP의 관계

  1. 프로토콜과 아키텍처 스타일:
    • HTTP: HTTP(하이퍼텍스트 전송 프로토콜)는 웹 상에서 데이터를 주고받기 위한 프로토콜이다. 이 프로토콜은 요청과 응답을 통해 클라이언트와 서버가 데이터를 교환하는 방식을 정의한다.
    • REST: REST(Representational State Transfer)는 특정 프로토콜에 의존하지 않는 아키텍처 스타일이다. 그러나 REST의 설계 원칙이 HTTP의 설계 철학과 잘 맞기 때문에, RESTful 시스템은 주로 HTTP 프로토콜을 기반으로 구현된다.
  2. REST의 주요 원칙과 HTTP:
    • 클라이언트-서버 구조: HTTP도 클라이언트와 서버 간의 상호작용을 기본 구조로 한다. REST는 이 구조를 명확히 하고 독립성을 강조한다.
    • 무상태성 (Stateless): HTTP는 기본적으로 무상태(stateless) 프로토콜이다. 각 요청은 독립적이며, 클라이언트와 서버 간의 상태가 저장되지 않는다. REST도 무상태성을 강조하여 서버가 클라이언트 상태를 기억하지 않도록 한다.
    • 캐시 가능 (Cacheable): HTTP는 응답에 Cache-Control 헤더 등을 통해 캐싱 전략을 지정할 수 있다. REST도 캐시 가능한 응답을 통해 성능 최적화를 권장한다.
    • 인터페이스의 통일성 (Uniform Interface): HTTP 메서드(GET, POST, PUT, DELETE 등)를 활용하여 일관된 인터페이스를 제공한다. REST는 이러한 일관성을 강조하며, 각 메서드가 특정한 기능을 수행하도록 한다.
  3. 리소스와 표현:
    • REST는 리소스를 URI(예: /users/1)를 통해 식별하며, 각 리소스의 상태는 다양한 표현(Representation) 형식(JSON, XML 등)으로 전송된다.
    • HTTP도 URL을 통해 리소스를 식별하고, Content-Type 헤더를 통해 데이터 형식을 지정하여 다양한 표현을 전송할 수 있다.
  4. 결론: REST와 HTTP는 설계 철학과 원칙에서 많은 유사함을 갖고 있다. 이러한 이유로 RESTful 서비스는 주로 HTTP를 기반으로 구현된다. RESTful 아키텍처는 HTTP의 기능을 자연스럽게 확장하고 활용하여, 웹 서비스의 유연성과 확장성을 극대화한다.

참고

WIKIPEDIA - REST

[CS] Code-on-Demand가 잘 쓰이지 않는 이유는 무엇일까? (aka 유일한 optional 원칙 in REST API)

IBM - REST API란 무엇인가요?

[WEB] 🌐 REST API 구성/특징 총 정리