REST API는 인터넷과 같은 네트워크를 통해 두 시스템(클라이언트와 서버) 간의 데이터 표현 및 통신에 대한 REST( 표현 상태 전송 ) 모델을 준수하는 유형의 애플리케이션 프로그래밍 인터페이스 (API)입니다. REST API는 내부 및 타사 애플리케이션 간의 정보 교환을 지원하고, 기업이 여러 엔드포인트를 애플리케이션 생태계에 통합할 수 있도록 합니다.
메모: 엄밀히 말해서 REST는 모델을 지칭하며, 이를 준수하는 API를 지칭하는 형용사가 아닙니다. 이에 대한 적절한 용어는 RESTful API 입니다. 그러나 REST API가 더 일반적인 용법이므로 이 글에서는 REST API를 사용합니다.
REST는 앞서 언급했듯이 Representational State Transfer의 약자로, 2000년 컴퓨터 과학자 로이 필딩이 만든 아키텍처 스타일입니다. REST는 개발자에게 유연성을 제공하므로 마이크로서비스 아키텍처 에서 애플리케이션을 연결하는 데 이상적입니다.
REST는 앱과 API가 RESTful로 간주되기 위해 따라야 하는 6가지 제약 조건을 정의합니다.
이러한 제약에 대해 더 자세히 알아보려면 Wikipedia를 참조하세요.
균일한 인터페이스는 전반적인 시스템 아키텍처를 단순화하고 상호작용 가시성을 향상시킵니다. 또한 정보가 표준 형식으로 전송되는지 확인하기 위한 특정 요구 사항도 있습니다.
REST 인터페이스를 균일하게 만드는 데는 네 가지 제약 조건이 있습니다.
클라이언트-서버 아키텍처는 클라이언트, 서버, 리소스로 구성됩니다. 사용자 인터페이스(클라이언트 제어)와 데이터 저장소(서버 제어)를 분리하면 클라이언트와 서버 구성 요소가 자율적으로 발전할 수 있습니다. 또한 이를 통해 여러 플랫폼에서 클라이언트 사용자 인터페이스의 이식성과 서버의 확장성이 간소화됩니다.
인터넷에서는 클라이언트-서버 상호작용이 HTTP를 통해 이루어집니다.
클라이언트-서버 통신에서 무상태란 서버가 클라이언트나 클라이언트와 설정된 세션에 대한 정보를 저장하지 않는다는 것을 의미합니다. 각 메시지에서 클라이언트가 세션 관련 정보를 표현하는 방식은 서버가 이전 메시지의 맥락 없이도 해당 정보를 단독으로 이해할 수 있도록 해야 합니다. 이를 통해 서버 부하가 줄어들고 대용량 애플리케이션의 성능이 향상됩니다.
클라이언트는 자신이 서버에 직접 연결되어 있는지 아니면 역방향 프록시나 로드 밸런서와 같은 중개자에 연결되어 있는지 알 필요가 없습니다(일반적으로 알 수 없습니다). 중개 서버는 확장성을 개선하는 데 도움이 되며 보안을 처리하는 데 사용할 수 있으므로 서버는 비즈니스 로직에만 책임을 집니다.
HTTP 클라이언트와 중개자는 서버 응답을 캐시하여 서버의 부하를 줄이고 최종 사용자에게 데이터를 전달하는 속도를 높일 수 있습니다. 서버는 응답이 캐시 가능한지 또는 캐시 불가능한지 여부를 표시해야 하며, 후자는 후속 최종 사용자 요청에 대한 응답이 정확하고 최신 상태(잠재적으로 "오래되지 않음")인지 확인합니다. 클라이언트는 고유 식별자인 URL을 통해 리소스에 액세스하므로 클라이언트는 리소스 수준에서 캐시할 내용을 결정할 수 있습니다.
주문형 코드란 서버가 실행 가능한 코드를 보내 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있음을 의미하며, 클라이언트가 직접 기능을 구현할 필요가 없습니다. 코드 온디맨드 제약은 선택 사항입니다.
REST에서 가장 중요한 데이터 표현 또는 추상화는 리소스입니다. REST 리소스는 디지털 문서부터 비디지털 객체까지 모든 유형의 추상화된 정보가 될 수 있습니다. 특정 시점의 리소스 상태를 리소스 표현 이라고 합니다.
리소스 표현에는 세 가지 부분이 있습니다.
REST API는 고유한 URI에서 접근할 수 있는 상호 연결된 리소스(또는 리소스 모델 )의 조합으로 구성됩니다. 클라이언트는 응답 내의 관련 리소스와 URI에 연결하여 유연한 기능을 구현할 수 있습니다. 일반적으로 REST API에 대한 요청은 HTTP GET 요청 형식으로 전송되고, 서버는 종종 응답을 JSON 형식으로 지정합니다.
다음 HTTP 요청 방법은 지정된 방식으로 리소스에 대해 작업을 수행하는 데 사용됩니다.
REST 아키텍처 스타일에서 리소스 식별자는 클라이언트-서버 상호 작용에 관련된 각 리소스를 고유하게 지정합니다.
"미디어 유형" 또는 데이터 형식의 표현은 리소스를 처리하는 방법을 정의합니다. REST API에서 모든 미디어 유형은 JSON을 기반으로 하며, 하이퍼미디어 (때로는 하이퍼텍스트 라고도 하지만 약간 다릅니다)입니다. 하이퍼미디어는 다른 미디어에 대한 링크가 있는 모든 콘텐츠를 말합니다. 애플리케이션 상태 엔진으로서의 하이퍼미디어(HATEOAS)는 REST 아키텍처를 독특하게 만드는 요소입니다.
메모: 로이 필딩에 따르면 API가 REST API로 간주되려면 하이퍼미디어를 사용해야 합니다 . 하지만 오늘날 많은 API 설계자들은 하이퍼미디어/하이퍼텍스트를 사용하지 않음에도 불구하고 종종 자신의 API를 유행어로 "REST[ful]"이라고 부릅니다.
리소스 표현은 자체 설명적이어야 합니다. 즉, API는 자체 컨텍스트 내에서 이해될 수 있어야 합니다. 자체 설명적 표현을 사용하면 클라이언트는 리소스가 어떤 범주에 속하는지 알 필요가 없으며 대신 리소스와 관련된 미디어 유형에 따라 작동합니다.
오늘날 대부분의 기업은 앱 간 통신을 위해 기본적이고 혁신적이며 중요한 기능을 제공하는 자체 개발 API 및 타사 API를 사용합니다. 이러한 API의 대부분은 REST API입니다. REST가 요구하는 특정 통신 표준을 통해 안전하고 효율적이며 신뢰할 수 있는 정보 교환이 가능하기 때문입니다. REST API는 모든 프로토콜과 함께 작동할 수 있습니다.
REST API는 RESTful 웹 서비스가 응답을 보내기 전에 요청을 인증하기 때문에 안전합니다. 사용자 신원을 확인하기 위해 REST API는 HTTP 인증( 기본 토큰과 Bearer 토큰 모두), API 키, OAuth를 사용하여 로그인 액세스를 제공합니다.
REST API의 다른 이점은 다음과 같습니다.
REST는 여전히 클라이언트와 서버 애플리케이션을 연결하는 데 가장 널리 사용되는 아키텍처이지만 GraphQL (2012년 Facebook에서 개발하고 2015년 오픈 소스화)은 REST에 대한 대안으로 설계되었습니다. GraphQL API는 필요한 모든 데이터를 단일 요청으로 표준화된 형태로 요청하기 때문에 REST API보다 효율적이지만 REST가 뛰어난 몇몇 영역도 여전히 존재합니다. GraphQL은 학습 곡선이 가파르고 REST보다 캐시하기가 훨씬 어렵습니다. 또한, 애플리케이션은 종종 리소스에 의해 구동되며 GraphQL과 같은 쿼리 언어가 필요하지 않습니다. 즉, 각 모델에는 장단점이 있으며, 기업은 둘 다 선택하여 사용할 수 있습니다.
REST API의 유연성은 확실히 장점입니다. 하지만 너무 많은 유연성은 잠재적으로 느리거나 손상된 API를 설계하는 결과를 초래할 수도 있습니다. 이러한 이유로 많은 개발자는 OpenAPI 사양을 사용하여 API 문서를 게시, 관리하고 생성하기로 선택합니다.
F5 NGINX Management Suite 의 일부인 API Connectivity Manager는 REST API에 대한 OpenAPI 사양을 지원합니다. API Connectivity Manager는 API 개발자 경험을 핵심으로 설계되었습니다. 개발자 포털과 API 게이트웨이에 API를 게시하기 위한 원활한 통합을 갖춘 가벼운 클라우드 기반 API 관리 솔루션입니다.
API Connectivity Manager 와 Instance Manager가 포함된 NGINX Management Suite의 30일 무료 평가판을 시작하세요.