웹개발

[웹개발] REST API(1)

재담 2022. 3. 3. 23:34

REST(REpresentational State Transfer)

REST는 월드 와이드 웹(WWW)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 개념은 네트워킹 문화에 널리 퍼져있다. 엄격한 의미의 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP 위에서 SOAP이나 쿠키를 통한 세션 트래킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

 

REST라는 용어는 로이 필딩의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 필딩의 REST 원리를 따라는 시스템은 종종 RESTful이란 용어로 지칭된다.

 

REST의 등장 배경

단순히 하나의 브라우저만 지원하면 되었던 과거와는 달리 최근의 서버 프로그램은 웹 브라우저는 물론, 아이폰, 안드로이드 등 다양한 통신에 대응할 수 있어야 한다. 따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었다. 이런 과정에서 개발자들은 클라이언트를 전혀 고려하지 않고 메시지 기반, XML, JSON과 같은 클라이언트에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되면서 서버와 클라이언트의 역할을 분리하게 되었다.

 

REST의 구성

자원(Resource) : HTTP URI 형태로 나타난다.

  • 모든 자원에 대한 고유한 ID가 존재하고, 이 자원은 서버에 존재한다.
  • 자원을 구별하는 ID는 /orders/id/1과 같은 HTTP URI이다.

 

행위(Verb) : HTTP Method로 나타낸다.

  • REST에서는 CRUD에 대한 동작을 나타낸다.
  • POST, GET, PUT, DELETE

 

표현(Respresentation) : HTTP Message Payload를 나타낸다.

  • 클라이언트가 자원의 상태에 대한 조작을 요청하면 서버는 이에 적절한 응답을 보낸다.
  • REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있다.
  • 현재는 대부분 JSON으로 주고받는다.

 

REST의 특징

Uniform Interface

  • REST는 HTTP 표준에만 따른다면 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일이다.
  • 앞서 현재는 대부분 JSON으로 데이터를 주고받는다고 했지만 꼭 JSON일 필요는 없다.
  • 웹 브라우저를 포함해서 HTTP 통신이 가능한 모든 클라이언트 플랫폼을 타깃으로 한다.
  • 이러한 범용성을 위해서 REST API의 HTTP Response Body는 JSON, XML 등 여러 플랫폼에서 사용하기 적절한 단순한 텍스트 포맷을 사용한다.

 

무상태성(Stateless)

  • 클라이언트의 각 요청에 대한 콘텍스트(세션, 로그인 정보)가 서버에 저장되어서는 안 된다.
  • 상태 정보를 저장하지 않으면 각 API 서버는 들어오는 요청만을 처리하면 되며, 세션과 같은 정보를 신경 쓸 필요가 없기 때문에 구현이 단순해진다.

 

캐시 처리 가능(Cacheable)

  • REST는 HTTP라는 기존의 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존의 인프라를 그대로 활용이 가능하다.
  • 대량의 요청을 효율적으로 처리하기 위해 캐시가 요구된다.
  • 캐시 사용을 통해 응답 시간이 빨라지고 REST 서버 트랜잭션이 발생하지 않기 때문에 전체 응답 시간, 성능, 서버의 자원 이용률을 향상할 수 있다.
  • Last-Modified 태그나 E-Tag를 이용하면 캐시를 구현할 수 있다.
  • 아래와 같이 클라이언트가 HTTP GET을 Last-Modified 값과 함께 보냈을 때, 콘텐츠에 변화가 없다면 REST 컴포넌트는 304 Not Modified를 리턴하며 클라이언트는 캐시에 저장된 값을 사용한다.

출처 : https://goodgid.github.io/REST-API/

 

자기 서술성(Self-descriptiveness)

  • REST API 메시지만으로도 그 요청이 어떤 행위를 하는지 알 수 있다.
  • 리소스와 메서드를 이용해서 어떤 메서드에 무슨 행위를 하는지 알 수 있으며, 메시지 포맷 역시 JSON을 이용해서 직관적으로 이해가 가능한 구조이다.

 

클라이언트 - 서버 구조

  • 클라이언트가 서버로 전송하는 데이터에 대한 의존성을 낮춰 준다.
  • 일관적인 인터페이스로 분리되어야 한다.
  • REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임진다.
  • 클라이언트는 사용자 인증이나 콘텍스트(세션, 로그인 정보) 등을 직접 관리 및 책임지는 구조로 역할이 나누어지고 있다.
  • 클라이언트와 서버에서 개발해야 할 내용들이 명확해지고, 서로의 개발에 있어서 의존성이 줄어들게 된다.

 

계층형 구조(Layered System)

  • 클라이언트와 서버가 분리되어 있기 때문에 중간에 프록시 서버, 암호화 계층 등 중간 매체를 사용할 수 있어 자유도가 높다.
  • 클라이언트 입장에서는 REST API 서버만 호출한다.
  • 고전적인 프로그램 아키텍처는 UI와 데이터 계층, 통신 계층이 모두 일체형으로 작성된 구조(모놀리식 아키텍처)를 따르는 경우가 많다.
  • REST는 UI 계층을 분리하여 클라이언트 프로그램의 범용성을 높인다.
  • 더 나아가서 대형 시스템의 개발에서는 하나의 응용프로그램을 계층별로 세분화하여 협업 및 배포의 효율성을 높인다.
  • 확장성 있는 구조를 띄는 마이크로 서비스 아키텍처를 지향하기도 한다.

Reference

저작자표시 (새창열림)