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