REST API

보고 배운 사이트 : aws.amazon.com

REST

Representational State Transfer
자원의 상태 전달
네트워크 아키텍처. 네트워크 디자인

API

Application Programming Interface
웹 API는 클라이언트와 웹 리소스 사이의 게이트웨이로도 볼 수 있다.
(게이트웨이 Gateway = 서로 다른 프로토콜이나 통신 환경을 가진 두 시스템을 연결하는 장치)

REST API

웹 서비스에서 자원에 접근하고 조작하기 위한 일련의 규칙과 표준을 따르는 API
HTTP 메서드 ( C: POST , R: GET , U: PUT , D: DELETE ) 와,
작업 결과를 나타내는 HTTP 상태 코드 ( 2xx: 성공 , 4xx: client page err , 5xx: server err )를 사용한다.

REST 특징

1. Client , Server 독립적
   클라이언트와 서버는 서로 독립적으로 분리 되어 있어야 한다.

2. Stateless
   요청에 대해 클라이언트의 상태를 서버에 저장하지 않는다.

3. Cache
   클라이언트는 서버의 응답을 Cache 할 수 있어야 한다.
   Cache 함으로 써 응답을 재사용할 수 있어야 하며, 이를 통해 서버의 부하를 낮춘다.

4. 계층화 Layered System
   서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등
   다양한 계층 형태로 서버 구성이 가능해야 하며, 이를 통해 서버를 확장할 수 있어야 한다.

5. 인터페이스 일관성
   인터페이스의 일관성을 지키고, 아키텍처를 단순화 시켜 작은 단위로 분리하여,
   클라이언트, 서버가 독립적으로 개선될 수 있어야 한다.

   1. 자원의 식별: 리소스 접근 시 URI를 사용한다.
      localhost:80/user/100
      리소스 = user
      식별자 = 100

   2. 일정 규약의 메시지를 통한 리소스 조작
      json, xml, html , text 등

   3. 자기 서술적 메시지
      GET , POST , PUT , DELETE 등 method 활용

   4. 애플리케이션 상태에 대한 엔진으로써 하이퍼미디어
      단순히 Client 요청에 대한 데이터만 응답 해주는 것이 아닌,
      관련 리소스에 대한 Link 정보까지 같이 포함되어져야 한다.

      하지만 4번 같은 경우, 실무에서 이러한 정보를 항상 함께 주고받는다면
      사용하지않는 정보를 항상 가공해야 하는 번거로움이 생기기 때문에 잘 활용되지 않는다.

      위의 사항들이 잘 지켜졌는지에 따라 REST를 잘 사용했는지 판단이 가능하다.

6. Code on Demand (Optional)
   자바스크립트 등 특정한 기능을 서버로부터 클라이언트가 전달받아 코드를 실행할 수 있어야 한다.