REST API란 무엇인가요?

AREST API는 인터넷과 같은 네트워크를 통해 두 시스템(클라이언트와 서버) 간에 데이터를 표현하고 통신하는 애플리케이션 프로그래밍 인터페이스(API)의 한 유형으로, 표현 상태 전송(REST) 모델을 준수합니다. REST API는 내부 애플리케이션과 서드 파티 애플리케이션 간의 정보 교환을 지원하며, 기업이 여러 엔드포인트를 애플리케이션 생태계에 통합할 수 있도록 합니다.

참고: 엄밀히 말하면 REST는 모델을 가리키는 용어이지, 해당 모델을 준수하는 API를 수식하는 형용사가 아닙니다. 이러한 API를 가리키는 정확한 용어는 RESTful API입니다. 하지만 REST API라는 표현이 더 일반적으로 사용되므로 이 문서에서도 이 표현을 사용합니다.

REST란 무엇인가요?

앞서 언급했듯이 REST는 표현 상태 전송을 의미하며, 컴퓨터 과학자 로이 필딩이 2000년에 고안한 아키텍처 스타일입니다. REST는 개발자에게 유연성을 제공하므로 마이크로서비스 아키텍처에서 애플리케이션을 연결하는 데 적합합니다.

REST는 앱과 API가 RESTful로 간주되기 위해 준수해야 하는 여섯 가지 제약 조건을 정의합니다:

일관된 인터페이스
클라이언트-서버 아키텍처
무상태성
계층화된 시스템
캐시 가능성
주문형 코드

이러한 제약 조건에 대한 자세한 내용은 Wikipedia에서 확인할 수 있습니다.

일관된 인터페이스

일관된 인터페이스는 전체 시스템 아키텍처를 단순화하고 상호작용의 가시성을 높입니다. 또한 정보가 표준화된 형식으로 전송되도록 하기 위한 구체적인 요구사항이 있습니다.

다음 네 가지 제약 조건을 통해 REST 인터페이스의 일관성을 유지할 수 있습니다:

각 리소스에는 URI와 같은 고유 식별자가 있으며, 메시지에 포함된 리소스 표현은 서버의 내부 표현과 분리되어 있습니다.
리소스 표현에는 클라이언트가 리소스의 상태를 수정하거나 삭제하는 데 충분한 정보가 포함됩니다.
각 메시지에는 메시지를 처리하는 방법을 설명하기에 충분한 정보가 포함되어 있습니다
서버는 하이퍼링크를 사용하여 클라이언트에 사용 가능한 리소스를 알려 주므로, 클라이언트가 서버 내부 구조를 알 필요가 없습니다.

클라이언트-서버

클라이언트-서버 아키텍처는 클라이언트, 서버, 리소스로 구성됩니다. 사용자 인터페이스(클라이언트가 제어)와 데이터 저장소(서버가 제어)를 분리하면 클라이언트와 서버 구성 요소가 서로 독립적으로 발전할 수 있습니다. 또한 여러 플랫폼에서 클라이언트 사용자 인터페이스의 이식성을 확보하고 서버의 확장성을 높이기가 쉬워집니다.

인터넷에서 클라이언트와 서버는 HTTP를 통해 상호 작용합니다.

무상태성

클라이언트-서버 통신에서 무상태성이란 서버가 클라이언트 또는 클라이언트와 설정된 세션에 관한 정보를 저장하지 않는 것을 의미합니다. 클라이언트는 각 메시지에 세션 관련 정보를 포함하여, 서버가 이전 메시지의 맥락 없이도 해당 메시지만으로 내용을 이해할 수 있도록 해야 합니다. 이를 통해 서버 부하를 줄이고 트래픽이 많은 애플리케이션의 성능을 향상할 수 있습니다.

계층형 시스템

클라이언트는 서버에 직접 연결되어 있는지, 아니면 리버스 프록시나 로드 밸런서 같은 중간 서버에 연결되어 있는지 알 필요가 없으며, 일반적으로 이를 구분할 수도 없습니다. 중간 서버는 확장성을 높이는 데 도움이 되며 보안을 처리하는 데도 사용할 수 있으므로, 서버는 비즈니스 로직만 담당하면 됩니다.

캐시 가능성

HTTP 클라이언트와 중개자는 서버 응답을 캐시하여 서버의 부하를 줄이고 최종 사용자에게 데이터를 더 빠르게 전달할 수 있습니다. 서버는 응답의 캐시 가능 여부를 명시해야 하며, 캐시할 수 없도록 지정하면 이후 최종 사용자의 요청에 대한 응답이 잠재적으로 '오래된' 상태가 아니라 정확한 최신 상태임을 보장할 수 있습니다. 클라이언트는 고유 식별자인 URL을 통해 리소스에 액세스하므로 리소스 수준에서 캐시할 대상을 결정할 수 있습니다.

주문형 코드

Code-on-Demand은 서버가 실행 가능한 코드를 전송하여 클라이언트 기능을 일시적으로 확장하거나 맞춤 설정할 수 있게 하는 방식으로, 클라이언트가 해당 기능을 직접 구현할 필요가 없습니다. Code-on-Demand 제약 조건은 선택 사항입니다.

리소스란 무엇인가요?

REST에서 가장 중요한 데이터 표현 또는 추상화는 리소스입니다. REST 리소스는 디지털 문서부터 비디지털 객체에 이르기까지 추상화된 모든 유형의 정보가 될 수 있습니다. 특정 시점의 리소스 상태를 리소스 표현이라고 합니다.

리소스 표현은 세 부분으로 구성됩니다:

데이터
메타데이터
하이퍼미디어 링크

REST API는 고유한 URI를 통해 액세스할 수 있는 상호 연결된 리소스의 집합(또는 해당 리소스 모델 )으로 구성됩니다. 클라이언트는 응답 내에서 관련 리소스와 URI를 연결하여 유연한 기능을 구현할 수 있습니다. 일반적으로 REST API에 대한 요청은 HTTP GET 요청 형식으로 전송되며, 서버는 응답을 JSON 형식으로 제공하는 경우가 많습니다.

다음 HTTP 요청 메서드는 리소스에 대해 명시된 방식으로 작업을 수행하는 데 사용됩니다:

GET – 리소스 로드
POST – 새 리소스 생성
PUT – 기존 리소스 수정
DELETE – 리소스 삭제

리소스 식별자

REST 아키텍처 스타일에서 리소스 식별자는 클라이언트-서버 상호 작용에 관여하는 각 리소스를 고유하게 식별합니다.

하이퍼미디어

데이터 형식을 표현하는 “미디어 유형”은 리소스를 처리하는 방법을 정의합니다. REST API에서 모든 미디어 유형은 JSON을 기반으로 하며 하이퍼미디어입니다(때로는 하이퍼텍스트라고도 하지만, 엄밀히 말하면 약간 다릅니다). 하이퍼미디어는 다른 미디어로 연결되는 링크가 포함된 모든 콘텐츠를 의미합니다. REST 아키텍처를 고유하게 만드는 것은 애플리케이션 상태 엔진으로서의 하이퍼미디어(HATEOAS)입니다.

참고: Roy Fielding에 따르면 API가 REST API로 간주되려면 하이퍼미디어를 사용해야 합니다. 하지만 오늘날 많은 API 설계자는 하이퍼미디어/하이퍼텍스트를 사용하지 않으면서도 유행어처럼 자신의 API를 “REST[ful]”이라고 부르곤 합니다.

자기 서술적

리소스 표현은 자체 설명적이어야 합니다. 즉, API가 자체 컨텍스트 내에서 스스로를 이해할 수 있도록 정보를 제공합니다. 자체 설명적 표현을 사용하면 클라이언트는 리소스가 어떤 범주에 속하는지 알 필요 없이 해당 리소스와 연결된 미디어 유형을 기반으로 동작합니다.

REST API의 이점

오늘날 대부분의 기업은 기본적이고 혁신적이며 핵심적인 기능을 제공하는 애플리케이션 간 통신을 위해 자체 개발 API와 서드 파티 API를 사용합니다. 이러한 API의 대다수는 REST API입니다. REST에서 규정하는 구체적인 통신 표준을 통해 안전하고 효율적이며 신뢰할 수 있는 정보 교환이 가능하기 때문입니다. 또한 REST API는 모든 프로토콜과 함께 사용할 수 있습니다.

REST API는 RESTful 웹 서비스가 응답을 보내기 전에 요청을 인증하므로 보안성도 뛰어납니다. 사용자 신원을 확인하기 위해 REST API는 HTTP 인증 방식인 Basic 및 Bearer Token과 API 키, OAuth를 사용하여 로그인 접근을 인증합니다.

REST API의 다른 이점은 다음과 같습니다:

시스템 확장성 – REST는 클라이언트와 서버 간의 상호 작용을 최적화하므로 REST API를 효율적으로 확장할 수 있습니다. RESTful 무상태성 제약 조건은 서버가 이전 요청의 정보나 이전 요청에 관한 정보를 저장할 필요가 없으므로 서버 부하를 줄여 줍니다. 또한 캐시 가능성은 잠재적으로 병목 현상을 일으킬 수 있는 클라이언트-서버 간 상호 작용 횟수를 줄여 줍니다. 그 결과 확장 가능한 고성능 API를 구현할 수 있습니다.
개발자를 위한 유연성 – 많은 엔터프라이즈 애플리케이션은 내부 또는 서드 파티 API와 통신해야 합니다. RESTful 웹 서비스는 클라이언트와 서버의 분리를 지원하므로 각각 독립적으로 발전할 수 있습니다.
기술적 독립성 – REST API는 관련 앱을 개발하는 데 사용되는 프로그래밍 언어와 프레임워크에 종속되지 않습니다. 클라이언트 앱과 서버 앱이 동일한 언어나 프레임워크를 사용할 필요가 없으며, API 설계나 통신 프로세스에 영향을 주지 않고 언어나 프레임워크를 변경할 수 있습니다.

REST API와 GraphQL 비교

REST는 여전히 클라이언트와 서버 애플리케이션을 연결하는 데 가장 널리 사용되는 아키텍처이지만, GraphQL (2012년 Facebook에서 개발되어 2015년에 오픈 소스로 공개됨)은 REST의 대안으로 설계되었습니다. GraphQL API는 필요한 모든 데이터를 표준화된 형식으로 한 번의 요청을 통해 가져오므로 REST API보다 효율적이지만, REST가 더 뛰어난 영역도 여전히 존재합니다. GraphQL은 학습 난도가 높고 REST보다 캐싱하기가 훨씬 어렵습니다. 또한 애플리케이션은 리소스를 중심으로 작동하는 경우가 많아 GraphQL과 같은 쿼리 언어가 필요하지 않을 수 있습니다. 이처럼 각 모델에는 장단점이 있으며, 조직은 두 가지를 모두 사용할 수도 있습니다.

NGINX는 어떻게 도움이 될까요?

REST API의 유연성은 분명 장점입니다. 하지만 지나친 유연성은 잠재적으로 느리거나 제대로 작동하지 않는 API를 설계하게 만들 수도 있습니다. 이러한 이유로 많은 개발자는 OpenAPI 명세을 사용하여 API를 게시 및 관리하고 문서를 생성합니다.

API Connectivity Manager, F5 NGINX Management Suite의 일부로서 REST API용 OpenAPI 사양을 지원합니다. API Connectivity Manager는 API 개발자 경험을 핵심으로 설계되었습니다. 개발자 포털과 API 게이트웨이에 API를 게시할 수 있도록 원활하게 통합되는 경량 클라우드 네이티브 API 관리 솔루션입니다.

NGINX Management Suite 30일 무료 체험판을 시작해 보세요。NGINX Management Suite에는 API Connectivity Manager와 Instance Manager가 포함되어 있습니다.