[RESTful] REST API

---

# REST

REpresentational State Transfer

 

WWW(World Wide Web)와 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식이다.

기존 웹의 기술과 HTTP 프로토콜을 그대로 활용하기에 웹의 장점을 최대한 활용할 수 있는 아키텍처이다.

 

자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 것을 의미한다.

즉, 자원의 표현에 의한 상태 전달이다.

 

• HTTP URI를 통해 Resource(자원)를 명시하고
• HTTP Method를 통해 해당 자원에 대한 CRUD Operation(상태)을 적용하는 것을 의미한다.
• Request가 완료되면 Server는 특정 Representation(표현방식)을 Response로 보내준다.
• 즉, 자원 기반의 구조 설계의 중심에 Resource가 있고, HTTP Method를 통해 Resource를 처리하도록 한다.

 

 

---

## 구성 요소

• Reource 자원 : URL
  • 모든 자원에는 고유 ID가 존재하고, 이 자원은 Server에 존재한다.
  • 자원을 구별하는 ID는 HTTP URL이다.
  • Client는 URL을 통해 자원을 지정하고 해당 자원의 상태에 대한 조작을 Server에 요청한다.

 

• Verb 행위 : HTTP Method
  • HTTP Method를 사용한다.

https://hoooon-s.tistory.com/218?category=855277 

[Computer Science] HTTP - HyperText Transfer Protocol 이란

 

 

• Representation of Resource 표현
  • Client가 자원의 상태에 대한 조작을 요청하면, Server는 적절한 응답(Representation)을 보낸다.
  • REST에서 하나의 자원은 JSON, XML, TEXT 등 다양한 형태로 응답된다.

 

 

 

---

 

## 특징

• Client - Server 구조
  • Client는 유저와 관련된 처리 (사용자 인증, 세션, 로그인 등)를 담당한다.
  • Server는 REST API를 제공하고 비즈니스 로직 처리 및 저장을 담당한다.
  • Client와 Server간 의존성이 줄어든다.

 

• Stateless 무상태
  • 연결을 유지 하지 않는 HTTP를 이용하기에 무상태성을 갖는다.
  • 따라서 Client의 context를 Server에 저장하지 않는다.
    • 세션과 쿠키 같은 context 정보를 신경쓰지 않아 구현이 단순하다.
  • Server에서는 작업을 하기 위해 상태 정보를 기억할 필요가 없고 들어온 요청만 처리하면 된다.

 

• Cachable 캐시 처리 가능
  • HTTP 웹 표준을 사용하기에 기존 웹에서 사용하는 인프라를 그대로 사용한다.
  • 즉, HTTP가 가진 강력한 기능 중 하나인 캐싱 기능을 사용할 수 있다.
  • 대량의 요청을 처리하기 위해 캐싱 기능이 필요하다.
  • 캐싱 기능을 활용하여 REST Server 트랜잭션이 발생하지 않기에 응답 시간, 성능, 서버의 자원 활용에 효과적이다.

 

• Self-Descriptiveness 자체 표현 구조
  • JSON을 이용한 메시지 포맷을 이용하여 직관적으로 이해할 수 있고, REST API 메시지만으로 어떤 행위를 하는지 표현할 수 있다.

 

• Layerd System 계층 구조
  • Client는 REST API Server만 호출한다.
  • REST Server는 다중 계층으로 구성될 수 있다.
    • API는 비즈니스 로직을 수행하고, 그 앞단에 로드 밸런서, 보안, 암호화, 인증 등을 추가할 수 있다.
    • Proxy, Gateway 같은 네트워크 기반의 중간 매체를 사용할 수 있다.

 

• Uniform Interface 인터페이스 일관성
  • URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스를 통해 수행한다.
  • HTTP 표준만 따르면 모든 플랫폼에서 사용이 가능하다.
  • 즉, 특정 언어나 기술에 종속되지 않는다.

 

 

---

 

## 장점

• HTTP 인프라를 그대로 사용하므로 REST API 사용을 위한 별도 인프라 구축이 필요 없다.
• HTTP 표준을 따르는 모든 플랫폼에서 사용이 가능하다.
• 하이퍼미디어 API의 기본을 지키면서 범용성을 보장한다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 알 수 있다.

 

## 단점

• REST는 point to point 통신 모델을 기본으로 하기에, Client <-> Server 간 상호 연결을 하는 서비스엔 맞지 않다.
• REST는 URI, HTTP를 이용하는 아키텍쳐링 방법만 담고 있기에, 보안과 통신 규약 같은 정책은 개발자가 처리해야 한다.
• HTTP에 의존적이고, CRUD 4가지 메소드만 제공한다.

 

 

---

 

# API

Application Programming Interface

 

응용 프로그램에서 사용할 수 있게 제공하는 인터페이스를 의미한다.

 

 

 

---

 

# RESTful API

REST 아키텍처의 제약 조건을 준수하는 API를 의미한다.

 

• Client Side를 정형화된 플랫폼이 아닌 PC, APP 등 제약을 두지 않는 것을 목표로 하기에 RESTful 하게 API를 개발해야 한다.
• 과거에는 Client 플랫폼이 명확했지만, 현재는 다양한 플랫폼이 등장하여 그에 맞춰 일일이 Server를 만드는 것은 비효율적이다.
• 그렇기에, Client Side를 고려하지 않고 메시지 기반, XML, JSON과 같은
• Client에서 바로 객체로 치환 가능한 형태의 데이터 통신을 지향하게 되었다.
• 그리고 이러한 통신을 지향하면서 자연스레 Client-Server 구조로 역할이 분리되었다.

 

 

---

참고

• https://hanamon.kr/rest-api/