IT 지식

REST API의 개념과 동작 방식

JasonM 2023. 5. 27. 01:44
반응형

우리는 휴대폰에서 좋아하는 소셜 미디어 앱을 열고, 태블릿에서 최신 뉴스를 읽고, 컴퓨터에서 여행 상품을 검색하거나, 스트리밍 서비스를 통해 좋아하는 프로그램을 시청합니다.

기술적인 관점에서 이런 행위의 공통점은 바로 REST API를 사용하여 인터넷에서 정보를 가져온다는 것입니다.

소셜 미디어(SNS)와 같은 일반적인 웹사이트나 모바일 애플리케이션을 열면 다양한 탐색 옵션이 포함된 상단 또는 하단 메뉴, 경우에 따라 추가 정보가 포함된 사이드바나 햄버거(?) 아이콘으로 표시되는 숨겨진 메뉴, 그리고 주요 콘텐츠를 보여주는 메인 영역이 표시됩니다. 이런 화면들에서 아래로 스크롤하면 화면이 계속 업데이트되어 더 많은 콘텐츠를 보여줍니다. 
 
사실 웹사이트나 모바일 앱을 통해 우리 눈에 보이는 화면은 단지 정형화 된 프레임워크일 뿐입니다. 웹사이트는 통신을 위한 물리적 헤더 정보나 콘텐츠 영역에 표시할 게시물의 화면 구조를 제공하지만 실제 콘텐츠는 제공하지 않습니다. 사이트를 방문하면 이 전체 프레임워크가 다운로드되어 브라우저에서 실행되기 시작하고 해당 서비스에 대한 자동화된 요청을 Representational State Transfer Application Programming Interface(REST API)로 보냅니다. 

예를 들어 "최신 게시물 50개를 알려줄 수 있나요?"라고 서버에 물어보면, REST API는 게시물 자체가 포함된 데이터 패키지를 전송하여 응답하고 프레임워크는 응답받은 데이터의 가져와서 템플릿 내의 올바른 위치에 배치합니다. 목록의 끝으로 스크롤하면 다른 REST 요청이 전송, 수신 및 구문 분석됩니다. 스마트폰을 사용하면 동일한 REST 요청이 특정 운영 체제 전용 애플리케이션에서 전송, 수신 및 구문 분석됩니다.

간단히 말해서 REST API를 사용하면 화면을 구성하는 요소들과 콘텐츠를 완전히 분리할 수 있으며, 전체 페이지가 아닌 콘텐츠만을 소비하는 초고속 애플리케이션을 구축할 수 있기 때문에 브라우저, 모바일, 태블릿 등 어느 곳에서나 작동하는 더 빠른 솔루션을 만들 수 있습니다. 

이러한 REST API의 작동 방식과 이를 사용하는 방법을 아는 것이 강력한 웹 사이트 및 웹 기반 애플리케이션을 구축하는 데 핵심입니다.
 
 

REST API의 역할

REST API가 어떤 역할을 하는지 이해하기 위해 도서관을 예로 들어보겠습니다.
 
도서관에는 책이 있고, 어떤 책이 있는지 검색을 하고 책을 빌리거나 변경하고 다 읽은 책을 반납하려는 사람들이 있습니다. 그리고 도서관에는 사람들이 요청한 책을 찾아오거나 반납하는 등의 역할을 하는 사서가 있습니다.
 
REST API를 사용하는 애플리케이션의 경우에는 이렇게 볼 수 있습니다.

한쪽에는 사용자가 있습니다. 사용자가 사용하는 웹 애플리케이션, 모바일 앱, 스마트 워치 또는 데이터 액세스를 사용하는 모든 인터페이스이며, 도서관에 방문한 사람들이라고 생각할 수 있습니다.

다른 쪽에는 데이터 저장소, 일반적으로 데이터베이스, 데이터베이스 서버 또는 다른 유형의 서버가 있습니다. 이것들은 도서관에 저장되어 있는 수많은 책이라고 볼 수 있습니다.

그리고 REST API는 사용자와 데이터 저장소 사이에서 요청과 응답을 수신, 처리 및 처리합니다. 도서관의 사서와 같은 역할이라고 말할 수 있습니다.

 

REST API의 동작 방식

특정 위치의 리소스를 가져오는 경우

  1. 사용자(Client)는 리소스를 얻기 위해 특정 경로(endpoint)로 요청을 제출
  2. REST API는 해당 요청을 수신
  3. 요청된 리소스를 식별
  4. 어떤 데이터를 수집해야 하는지 파악
  5. 요청된 형식과 일치하는 데이터 표현을 생성
  6. 요청에 대한 응답에 필요한 모든 정보를 묶어서 리소스를 요청한 사용자에게 전송
    (이 응답에는 리소스 ID와 같은 메타데이터가 포함된 응답 헤더, 사용 가능한 작업에 대한 하이퍼링크, 응답이 전송되었을 때 이 응답이 갖는 미디어 형식 및 기타 정보를 포함)
  7. 사용자(Client)의 영역에서는 응답 데이터를 수신
  8. 데이터를 의미 있는 것으로 변환
  9. 화면에 가공된 데이터를 출력 (REST API는 화면의 처리가 완료되고 다음 요청이 올 때까지 기다립니다.)

 

사용자가 특정 위치의 리소스를 변경요청 하는 경우

  1. 위에서 리소스 요청을 통해서 받은 컨텐츠의 ID 값을 사용하여 ID에 해당되는 고유 리소스의 변경을 요청
  2. REST API는 요청을 수신
  3. ID가 포함된 요청이므로 이를 기존 리소스에 대한 요청으로 인식
  4. 요청된 미디어 형식을 기록
  5. 요청된 리소스를 식별
  6. 요청된 데이터를 데이터 저장소에 대해 작동하는 미디어 형식으로 변환
  7. 변경 사항을 제출
  8. 사용자(Client)에게 모든 것이 예상대로 진행되었음을 알리는 성공 메시지와 함께 리소스의 새로운 표현을 반환


위에서 REST API에 요청을 보내는 사용자(Client)가 하나만 있는 경우에 대해 작동 방식을 설명했지만, 실제 대부분의 애플리케이션에는 요청을 하는 클라이언트가 몇 명, 수백, 수천, 수백만 명이 있을 수 있는 반면 사서는 한명에서 수십명 정도이기 때문에 사서들은 매우 바쁘게 일해야 할 수도 있습니다. 하지만 모든 REST API의 작업은 완전히 동일하게 진행되기 때문에 적절한 인원의 사서를 배치한다면 동일한 업무를 여러명이 나누어서 처리하기만 하면 됩니다.


 

반응형

 

그래서 REST API란 대체 무엇인가?


REST API는 Representational State Transfer Application Programming Interface의 약어입니다.
REST API는 웹 애플리케이션 개발에 필수적이며 모든 웹 개발의 중심이 되고 있습니다.

Representational State Transfer 또는 REST는 효율적이고 신뢰할 수 있으며 확장 가능한 시스템을 구축할 수 있는 소프트웨어 아키텍처 설계 규약들을 나타냅니다.

따라서, REST는 특정 기술이 아니라 동사(Verbs)라고 하는 표준 메서드 집합을 수신하고, 리소스라고 하는 일반적으로 JSON 또는 XML과 같은 표준화된 구조 데이터를 반환하여 예측 가능하고 일관된 출력과 동작을 생성하는 데이터 아키텍처 및 디자인 방법론입니다.

이해를 위해 일반적인 웹 사이트를 생각해 보면, 

각 페이지는 아래와 같이 구성 됩니다.

  • 콘텐츠를 포함한 하나의 HTML
  • 이미지와 같은 참조 항목
  • 문서가 브라우저에 표시되는 방식을 설명하는 하나 이상의 스타일 시트 (CSS)
  • 문서(HTML)나 스타일 시트 (CSS) 중 하나를 조작하거나 또는 둘 모두를 조작하는 일부 JavaScript를 포함하는 단일 HTML 문서


방문자가 한 페이지에서 다른 페이지로 이동할 때 특정 HTML 문서 형식으로 웹 리소스를 가리키는 URL(Universal Resource Locator) 요청을 서버에 보냅니다. 서버는 인접한 파일과 함께 문서를 브라우저에 반환하여 이전 콘텐츠를 모든 새 콘텐츠로 대체하는 방식으로 응답합니다. 하지만 이런 방식은 잘 작동하지만 리소스를 많이 사용합니다. 각각의 새 페이지에는 완성된 HTML 문서가 필요하며 문서는 브라우저에서 다운로드 및 렌더링되기 전에 개발자가 작성하거나 콘텐츠 관리 시스템에서 생성해야 합니다.

그럴다면 서버에서 생성되고 다운로드된 개별 문서로 구성된 웹 사이트 대신 웹 애플리케이션이
작동하는 방식을 살펴보면, 방문자가 사이트를 처음으로 로드하면 HTML 문서, 이미지와 같은 참조 항목, 스타일 시트 및 일부 JavaScript를 포함하여 응용 프로그램을 구성하는 모든 구성 요소가 다운로드됩니다. 컨텐츠가 HTML에 포함되지 않았다는 것만 빼면 처음 로딩은 웹사이트와 거의 동일 하다고 볼 수 있습니다. (물론 최초 로딩 시 필수적인 컨텐츠를 HTML문서에 포함시켜서 가져 올 수도 있습니다)

하지만 웹 애플리케이션은 화면에 보여지게 될 웹 리소스에 대한 Universal Resource Identifier (URI) 요청을 보내고 결과 데이터를 사용하여 현재 화면의 정해진 곳에 컨텐츠를 보여줍니다. 방문자가 현재 화면에서 다른 화면으로 이동할 경우, 윕 애플리케이션은 이전 데이터를 추가, 수정, 교체 또는 삭제하는 데 사용되는 애플리케이션의 다음 상태를 나타내는 웹 리소스에 대한 새 URI 요청을 보냅니다. 


핵심은 이러한 요청은 전체 새 파일 집합(HTML, CSS, Javascript 등)이 아니라 데이터 개체를 주고 받는다는 것입니다. 그리고 애플리케이션은 전체 새 페이지를 렌더링하지 않고도 데이터를 업데이트할 수 있습니다. 이를 통해 우리는 모두 동일한 REST 리소스를 사용하거나 소비하는 모바일 장치 및 플랫폼을 위한 웹 및 기본 앱에서 소위 단일 페이지 애플리케이션(Single page application)을 만들 수 있습니다.

실질적인 예를 하나 들자면, 컴퓨터와 스마트폰에서 Facebook을 방문할 때 두 개의 서로 다른 애플리케이션을 사용하지만 동일한 REST 리소스에서 동일한 데이터에 액세스합니다. 이 모든 것은 애플리케이션 프로그래밍 인터페이스 또는 API를 통해 제어됩니다.

API는 소프트웨어와 다른 소프트웨어 또는 하드웨어와 같은 다른 항목 간의 상호 작용을 가능하게 하는 소프트웨어 프로그램 내부에 존재하는 일련의 기능 및 규칙입니다.

REST API에서 API는 get, post, put 및 delete를 비롯한 부사를 통해 REST 리소스에 액세스하고 작업하는 데 사용되는 도구 모음입니다. REST 리소스를 Librarian으로, API를 그들과 대화하는 데 사용되는 언어로 생각할 수 있습니다. 다음 포스트에서 API의 Get, Post, Put, Delete 등 도구로 표현했던 메서드들을 구체적으로 다뤄보도록 하겠습니다.

반응형