REST API란?(Feat. SOAP)

이호영·2022년 5월 17일
0

이론

목록 보기
2/2

REST(RESTful)란?

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로 간주되려면 다음 기준을 따라야 합니다.

  1. 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

  2. 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

  • 스테이트리스(stateless): 스테이트리스 프로세스 또는 애플리케이션은 격리된 것으로 간주됩니다.
    과거 트랜잭션에 대한 정보 또는 참조가 저장되지 않기 때문입니다.
    각 트랜잭션은 모두 처음부터 시작됩니다.
    스테이트리스 애플리케이션은 하나의 서비스 또는 기능을 제공하며, 콘텐츠 전달 네트워크(CDN), 웹, 프린트 서버를 사용해 이러한 단기 요청을 처리합니다.
    이러한 스테이트리스 트랜잭션의 간단한 예로 검색창에 질문을 입력하고 엔터키를 누르는 형식으로 진행되는 온라인 검색입니다. 트랜잭션이 우발적으로 중단되거나 종료되면 새롭게 시작하면 됩니다. 스테이트리스 트랜잭션은 단일 요청에 대해 하나의 응답이 발생됩니다.
  1. 일부 클라이언트-서버 간 상호 작용의 필요성을 제거할 캐시 가능 데이터가 필요합니다.

  2. 애플리케이션 요구 사항별로 다른 형식이 아닌 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요합니다.

  • REST를 처음으로 제시한 Roy Fielding은 이를 “REST 아키텍처 스타일을 다른 네트워크 기반 스타일과 차별화하는 핵심적인 기능”이라고 설명합니다.
  1. 클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요합니다.

  2. 실행 가능한 코드를 전송해 서버가 클라이언트의 기능을 확장할 수 있게 해주는 코드 온디맨드가 필요합니다. 단, 가시성이 감소할 수 있으므로 이는 선택적 가이드라인입니다.

SOAP란?

웹 API가 확산됨에 따라, 정보 교환을 표준화하기 위해 SOAP(Simple Object Access Protocol)라는 프로토콜 사양이 개발되었습니다. SOAP로 설계된 API는 XML 메시지 형식을 사용하며 HTTP 또는 SMTP를 통해 요청을 수신합니다. SOAP를 사용하면 더 간편한 방법으로 애플리케이션을 다양한 환경에서 실행하거나 다양한 언어로 작성하여 정보를 공유할 수 있습니다.
또한, 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜입니다. 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 빌트인 룰을 적용하므로 페이지 로드 시간이 길어질 수 있습니다.
그러나 이러한 표준은 빌트인 컴플라이언스를 제공한다는 의미이므로 기업에서 선호하는 방식이기도 합니다. 빌트인 컴플라이언스 표준에는 보안과 안정적인 데이터베이스 트랜잭션의 기본 속성인 원자성, 일관성, 격리성, 내구성이 포함됩니다.

  1. 웹 서비스 보안(WS-security): 토큰이라고 불리는 고유 식별자를 통해 메시지를 보호하고 전송하는 방식을 표준화합니다.

  2. WS-ReliableMessaging: 불안정한 IT 인프라로 전송되는 메시지 간 오류 처리를 표준화합니다.

  3. 웹 서비스 주소지정(WS-addressing): 심층 네트워크에 라우팅 정보를 유지관리하는 대신, SOAP 헤더 내에 메타데이터로 해당 정보를 패키징합니다.

  4. 웹 서비스 기술 언어(WSDL): 웹 서비스가 무엇을 하는지, 해당 서비스의 시작과 종료 위치를 기술합니다.

데이터에 대한 요청이 SOAP API로 전송되는 경우 HTTP(웹 브라우저), SMTP(이메일), TCP 등의 다양한 애플리케이션 레이어 프로토콜을 통해 처리될 수 있습니다. 그러나 요청이 수신되면, 인간과 기계가 모두 읽을 수 있는 마크업 언어인 XML 문서 형식으로 반환 SOAP 메시지가 반환됩니다. SOAP API에 대한 완료된 요청은 브라우저에서 캐시할 수 없으므로 API로 재전송하지 않는 한 이후에 액세스할 수 없습니다.

REST와 SOAP의 차이

SOAP는 프로토콜이지만 REST는 아키텍처 스타일이라는 근본적인 차이가 있으며 따라서 RESTful 웹 API에는 공식적인 표준이 없습니다. Roy Fielding의 논문인 '네트워크 기반 소프트웨어 아키텍처의 구조적 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)'에 정의된 것처럼 RESTful 시스템의 다음 6가지 주요 제약 조건을 준수했을 때 RESTful API라고 간주할 수 있습니다.

  1. 클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.

  2. 스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.

  3. 캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.

  4. 계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.

  5. 코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.

  6. 통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.

  • 요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환되는 표현으로부터 분리됩니다.

  • 표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.

  • 자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.

  • 애플리케이션 상태 엔진으로서의 하이퍼미디어: REST 클라이언트는 리소스에 액세스한 후 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 찾을 수 있어야 합니다.

클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.

스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.

캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.

계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.

코드 온디맨드(옵션): 서버에서 실행 가능한 코드를 전송하여 클라이언트의 기능을 확대할 수 있습니다.

통합된 인터페이스: 이 제약 조건은 RESTful API 설계의 핵심이며 다음과 같은 4가지 측면을 포함합니다.

요청에서 리소스 식별: 리소스가 요청에서 식별되며 클라이언트로 반환되는 표현으로부터 분리됩니다.

표현을 통한 리소스 조작: 클라이언트가 리소스를 나타내는 파일을 수신합니다. 이 표현에는 조작 또는 삭제를 허용할 수 있도록 충분한 양의 정보가 포함되어야 합니다.

자기 기술적(Self-descriptive) 메시지: 클라이언트에 반환되는 각 메시지에는 클라이언트가 해당 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.

애플리케이션 상태 엔진으로서의 하이퍼미디어: REST 클라이언트는 리소스에 액세스한 후 하이퍼링크를 통해 현재 사용 가능한 다른 모든 작업을 찾을 수 있어야 합니다.

0개의 댓글