REST란 무엇인가?
REST는 RE (Representational State Transfer ) 의 약자 이며, 분산 하이퍼미디어 시스템을 위한 아키텍처 스타일입니다 . 로이 필딩은 2000년 그의 유명한 논문 에서 REST를 처음 제시했습니다. 그 이후로 웹 기반 API( 애플리케이션 프로그래밍 인터페이스 ) 를 구축하는 데 가장 널리 사용되는 접근 방식 중 하나가 되었습니다 .
REST는 프로토콜이나 표준이 아니라 아키텍처 스타일입니다. 개발 단계에서 API 개발자는 다양한 방식으로 REST를 구현할 수 있습니다.
다른 아키텍처 스타일과 마찬가지로 REST에도 기본 원칙과 제약 조건이 있습니다. 서비스 인터페이스를 RESTful 이라고 부르려면 이러한 원칙을 반드시 충족해야 합니다.
REST의 6가지 지침 원칙
REST는 설계의 단순성, 확장성, 그리고 무상태성을 촉진하는 몇 가지 제약과 원칙을 기반으로 합니다. RESTful 아키텍처의 여섯 가지 주요 원칙 또는 제약은 다음과 같습니다.
1.1. Uniform Interface
구성 요소 인터페이스에 일반성의 원칙을 적용하면 전체 시스템 아키텍처를 단순화하고 상호작용의 가시성을 향상시킬 수 있습니다. 여러 아키텍처 제약 조건은 균일한 인터페이스를 확보하고 구성 요소의 동작을 제어하는 데 도움이 됩니다.
다음 네 가지 제약 조건을 통해 균일한 REST 인터페이스를 구현할 수 있습니다.
- 리소스 식별 – 인터페이스는 클라이언트와 서버 간 상호작용에 관련된 각 리소스를 고유하게 식별해야 합니다.
- 표현을 통한 리소스 조작 – 리소스는 서버 응답에서 동일한 표현을 가져야 합니다. API 사용자는 이러한 표현을 사용하여 서버의 리소스 상태를 수정해야 합니다.
- 자체 설명적 메시지 – 각 리소스 표현은 메시지 처리 방법을 설명하는 데 충분한 정보를 포함해야 합니다. 또한 클라이언트가 해당 리소스에 대해 수행할 수 있는 추가 작업에 대한 정보도 제공해야 합니다.
- 애플리케이션 상태 엔진으로서의 하이퍼미디어 - 클라이언트는 애플리케이션의 초기 URI만 가져야 합니다. 클라이언트 애플리케이션은 하이퍼링크를 사용하여 다른 모든 리소스와 상호작용을 동적으로 구동해야 합니다.
간단히 말해, REST는 클라이언트와 서버 간의 상호작용을 위한 일관되고 통일된 인터페이스를 정의합니다. 예를 들어, HTTP 기반 REST API는 표준 HTTP 메서드(GET, POST, PUT, DELETE 등)와 URI(Uniform Resource Identifiers)를 사용하여 리소스를 식별합니다.
1.2. 클라이언트-서버
클라이언트-서버 디자인 패턴은 관심사 분리를 강화하여 클라이언트와 서버 구성 요소가 독립적으로 발전하는 데 도움이 됩니다.
사용자 인터페이스 문제(클라이언트)와 데이터 저장 문제(서버)를 분리함으로써 여러 플랫폼에서 사용자 인터페이스의 이식성을 개선하고 서버 구성 요소를 단순화하여 확장성을 개선합니다.
클라이언트와 서버가 발전하는 동안, 클라이언트와 서버 간의 인터페이스/계약이 끊어지지 않도록 해야 합니다.
1.3. Stateless
무상태성은 클라이언트에서 서버로 보내는 각 요청에 요청을 이해하고 완료하는 데 필요한 모든 정보가 포함되어야 함을 의미합니다.
서버는 이전에 서버에 저장된 컨텍스트 정보를 활용할 수 없습니다.
이러한 이유로 클라이언트 애플리케이션은 세션 상태를 완전히 유지해야 합니다.
1.4. Cacheable
캐시 가능 제약 조건은 응답이 암시적 또는 명시적으로 자신을 캐시 가능 또는 캐시 불가능으로 표시해야 한다는 것을 요구합니다.
응답이 캐시 가능한 경우 클라이언트 애플리케이션은 나중에 동일한 요청과 지정된 기간에 대해 응답 데이터를 재사용할 수 있는 권한을 얻습니다.
1.5. 계층 시스템
계층형 시스템 스타일은 구성 요소의 동작을 제한함으로써 아키텍처를 계층적 계층으로 구성할 수 있도록 합니다. 계층형 시스템에서는 각 구성 요소가 상호 작용하는 바로 그 계층 너머를 볼 수 없습니다.
계층형 시스템의 비전문가를 위한 예로는 MVC 패턴이 있습니다 . MVC 패턴은 관심사를 명확하게 분리하여 애플리케이션 개발, 유지 관리 및 확장을 용이하게 합니다.
1.6. Code on Demand (Optional)
REST를 사용하면 애플릿이나 스크립트 형태의 코드를 다운로드하고 실행하여 클라이언트 기능을 확장할 수도 있습니다.
다운로드된 코드는 사전 구현해야 하는 기능의 수를 줄여 클라이언트를 간소화합니다. 서버는 클라이언트에 제공되는 기능의 일부를 코드 형태로 제공할 수 있으며, 클라이언트는 해당 코드만 실행하면 됩니다.
요약
간단히 말해서 REST 아키텍처 스타일에서는 데이터와 기능이 리소스로 간주되고 URI( Uniform Resource Identifier )를 사용하여 액세스됩니다.
리소스는 간단하고 명확하게 정의된 연산을 통해 처리됩니다. 또한, 클라이언트가 HTML, XML, 일반 텍스트, PDF, JPEG, JSON 등 다양한 형식으로 콘텐츠에 접근할 수 있도록 리소스는 표현 방식과 분리되어야 합니다.
클라이언트와 서버는 표준화된 인터페이스와 프로토콜을 사용하여 리소스 표현을 교환합니다. 일반적으로 HTTP가 가장 많이 사용되는 프로토콜이지만, REST는 HTTP를 의무적으로 사용하지 않습니다.
리소스에 대한 메타데이터가 공개되어 캐싱 제어, 전송 오류 감지, 적절한 표현 형식 협상, 인증 또는 액세스 제어 수행에 사용됩니다.
그리고 가장 중요한 점은 서버와의 모든 상호작용이 상태 비저장이어야 한다는 것입니다.
이러한 모든 원칙은 RESTful 애플리케이션을 간단하고, 가볍고, 빠르게 만드는 데 도움이 됩니다.
참고
