REST API

 

REST API

REST(Representational State Transfer)의 약자로 특정 요청에 따른 표현 상태 전이를 표현한다는 의미일까. 위키백과의 설명을 빌리자면 네트워크 아키텍처 원리의 모음으로, 네트워크 아키텍처 원리란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP 위에서 SOAP이나 쿠키를 통한 세션 트래킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

-> 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

 

브라우저와 같은 웹클라이언트는 URL link와 같은 resource identifer를 통해 resource에 대해 어떤 요청을 하고 그 결과를 받게 된다. 이러한 요청 결과는 브라우저 화면에 새로운 내용이 디스플레이 되는 등의 방식으로 표현된다. 즉, 이 과정을 통해 브라우저 표현상태(Representational State)의 변경(Transfer)을 유발하게 된다. REST는 이러한 특성을 표현한 용어이다. resource는 웹이 제공하는 모든 정보 및 데이터를 의미하며, resource identifier는 resource에 대한 링크이다.

REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다.

 

REST API란?

• API(Application Programming Interface): 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
• REST API
  • 정의: REST 기반으로 서비스 API를 구현하는 것
• RESTful의 목적
  • 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것
  • 근본적인 성능 향상이 목적이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것이 주 동기

 

REST 아키텍처에 적용되는 6가지 제한 조건 (제한조건 준수한다면, 개별 컴포넌트 자유로운 구현 가능)

• 클라이언트/서버 구조(Client-Servcer) : REST 서버는 API 제공. 클라이언트와 서버에서 개발해야할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.
  • 서버 부분: 데이터를 저장하고 관리하는 부분
  • 클라이언트 부분: 해당 서버에 접속하여 데이터를 연람하는 부분
• 무상태(Stateless) : 각 요청 간 클라이언트의 콘텐스트가 서버에 저장되어서는 안된다.
  • API 서버는 들어오는 요청만을 단순히 처리하면 되기 때문에, 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
• 캐시처리가능(Cacheable)
  • 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
    • 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용할 수 있다.
    • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.

• 계층화(Layered System) : REST서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
  • 클라이언트는 REST API 서버만 호출한다. 
  • REST 서버는 다중 계층으로 구성될 수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 둘 수 있다.
    • API Server는 순수 비지니스 로직을 수행하고, 그 앞단에 보안, 로드밸런싱 등을 추가할 수 있음
    • 또한, 로드밸런싱, 공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있다.
  • PROXY, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
• 유니폼 인터페이스(Uniform Interface)
  • 자원(URI)에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미.
  • 구성 요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform) 해야한다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다. 
  • 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
  • HTTP Method를 사용하면, 하나의 URL으로 많은 representation을 할 수 있다.
• 자체 표현 구조(Self-descriptiveness) : REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현구조로 되었다.
  
  

REST API 단점

-> 표준의 부재 (Absence of standard): 관리의 어려움과 좋은(공식화 된) API 디자인 가이드가 존재하지 않음

-> 표준이 없어서 성공적인 REST API 사례를 근거로 암묵적인 규칙이 생김, RESTful하지 않아도 틀렸다고 할 수가 없다. 

해결 방법: 제대로 된 REST API 표준 가이드와,

 

출처: https://12bme.tistory.com/25 [길은 가면, 뒤에 있다.]