REST API(RESTful API)란 REST 아키텍처의 제약 조건을 준수하는 API를 뜻합니다. REST는 Representational State Transfer의 줄임말입니다.
REST는 프로토콜이나 표준이 아닌 아키텍처 원칙 세트입니다. API 개발자는 REST를 다양한 방식으로 구현할 수 있습니다.
RESTful API를 통해 요청이 수행될 때 RESTful API는 리소스 상태에 대한 표현을 요청자에게 전송합니다. 이 정보 또는 표현은 HTTP: JSON(Javascript Object Notation), HTML, XLT 또는 일반 텍스트를 통해 몇 가지 형식으로 전송됩니다. JSON은 그 이름에도 불구하고 사용 언어와 상관이 없을 뿐 아니라 인간과 머신이 모두 읽을 수 있기 때문에 가장 널리 사용됩니다.
API가 RESTful로 간주되려면 다음 기준을 따라야 합니다.
클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
일부 클라이언트-서버 간 상호 작용의 필요성을 제거할 캐시 가능 데이터가 필요합니다.
애플리케이션 요구 사항별로 다른 형식이 아닌 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요합니다.
클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요합니다.
실행 가능한 코드를 전송해 서버가 클라이언트의 기능을 확장할 수 있게 해주는 코드 온디맨드가 필요합니다. 단, 가시성이 감소할 수 있으므로 이는 선택적 가이드라인입니다.
웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었습니다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있습니다.
또한, 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜입니다. 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 빌트인 룰을 적용하므로 페이지 로드 시간이 길어질 수 있습니다.
그러나 이러한 표준은 빌트인 컴플라이언스를 제공한다는 의미이므로 기업에서 선호하는 방식이기도 합니다. 빌트인 컴플라이언스 표준에는 보안과 안정적인 데이터베이스 트랜잭션의 기본 속성인 원자성, 일관성, 격리성, 내구성이 포함됩니다.
웹 서비스 보안(WS-security): 토큰이라고 불리는 고유 식별자를 통해 메시지를 보호하고 전송하는 방식을 표준화합니다.
WS-ReliableMessaging: 불안정한 IT 인프라로 전송되는 메시지 간 오류 처리를 표준화합니다.
웹 서비스 주소지정(WS-addressing): 심층 네트워크에 라우팅 정보를 유지관리하는 대신, SOAP 헤더 내에 메타데이터로 해당 정보를 패키징합니다.
웹 서비스 기술 언어(WSDL): 웹 서비스가 무엇을 하는지, 해당 서비스의 시작과 종료 위치를 기술합니다.
데이터에 대한 요청이 SOAP API로 전송되는 경우 HTTP(웹 브라우저), SMTP(이메일), TCP 등의 다양한 애플리케이션 레이어 프로토콜을 통해 처리될 수 있습니다. 그러나 요청이 수신되면, 인간과 기계가 모두 읽을 수 있는 마크업 언어인 XML 문서 형식으로 반환 SOAP 메시지가 반환됩니다. SOAP API에 대한 완료된 요청은 브라우저에서 캐시할 수 없으므로 API로 재전송하지 않는 한 이후에 액세스할 수 없습니다.
SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없습니다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있습니다.
클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.
스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.
캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.
계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.
코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.
통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.
요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환되는 표현으로부터 분리됩니다.
표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.
자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
애플리케이션 상태 엔진으로서의 하이퍼미디어: REST 클라이언트는 리소스에 액세스한 후 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 찾을 수 있어야 합니다.
클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.
스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.
캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.
계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.
코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.
통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.
요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환되는 표현으로부터 분리됩니다.
표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.
자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
애플리케이션 상태 엔진으로서의 하이퍼미디어: REST 클라이언트는 리소스에 액세스한 후 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 찾을 수 있어야 합니다.