[DRF] REST & REST API

   - Django REST Framework 를 새로운 프로젝트에 사용하게 됐는데 이 전에 항상 말로만, 어렴풋이만 알고 있던 REST에 대해 확실히 잡고 가고자 한다. 

 

   - 우선 지금 프로젝트에 DRF를 쓰고자 하는 이유는 크게 아래와 같다.

      ~ 기존 Web홈페이지, Basecamp에서 상품에 예약(구매)을 추가할 수 있었던 것을 네이버, 마이리얼트립 등 다양한 플랫폼에 이제 상품을 올려 예약을 받게 되면서 예약 Request가 들어오는 경로가 다양해져 REST를 통해 프론트엔드와 백엔드의 구분히 명확하게 필요해졌다.

      ~ Request들어오는 플랫폼이 다양해지면서 백엔드가 업데이트되더라도 프론트와 완전히 분리될 필요가 생김 

 

   - 구조 

      ~ cloud 사진 참고 

 

   - REST (Representational State Transfer)

      ~ 웹과 같은 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일을 말한다. 즉 제약조건들의 집합이며 이 제약조건들을 모두 충족해야 진정한 의미의 REST이다.

   - REST 제약조건 

      1. Client Server

      2. Stateless

      3. Cache

      4. Uniform Interface

      5. Layered System

      6. Code On Demand (Optional) _ 서버에서 코드를 클라이언트를 보내서 실행시킬 수 있어햐 한다. (Javascript)

      * 기본적인 HTTP Protocol을 충족시켜주면 상위 제약 조건들이 충족되는데 4번은 그렇지 못 함

         1) Client Server : Client는 API등을 통해 Server에 요청을 보내고 서버는 요청을 받아 거절 혹은 승인하여 로직을 수행한 뒤 응답하여 클라이언트가 받는 1:1의 구조로 이루어 진다. 이렇게 명확한 역할 분담(클라이언트는 사용자 인증, 세션 등 정보 관리 & 서버는 데이터 관리 및 비즈니스 로직 수행)으로 서버는 API를 통해 더욱더 다양한 요청을 받을 수 있게 된다. 또한 이러한 구조 때문에 REST는 계층형 구조의 장점도 가진다. 즉 서버가 다중으로 구성될 수 있다는 의미인데 순수한 비즈니스 로직을 수행해주는 API서버가 있다면 그 앞에 사용자 인증, 암호화, 로드 밸런싱 등의 역할을 하는 계층을 추가하는 것 처럼 구조적으로 유연하게 구축할 수 있다는 거임 

         2) Stateless : 말 그대로 REST는 상태값, 기록을 저장하지 않는다. 더하여 사용자로부터 받는 컨텍스트들도 저장하지 않아 API요청할 때 받는 정보만을 API는 신경쓰면 되기 때문에 훨씬 코드는 가벼워지고 로직에만 집중할 수 있게 된다.

         3) Cacheable : API는 HTTP를 사용하고 있기 때문에 캐싱 기능을 이용하는 것이 가능하다. 가령 Client에서 Last-Modified태그 정보를 담아 GET API으로 요청하면 API는 그것을 받아 Last-Modified의 시간 이후로 변경이 없을 경우 304 NOT MODIFIED를 리턴한다. 이와 같이 가지고 있는 캐쉬값을 활용하며 서비스를 제공할 수 있다.

         4) Uniform Interface  : API는 URI를 식별자로 구분이 가능해야 한다. www.google.com은 구글의 메인 페이지를, 가령 to-do를 알려주는 사이트가 있다면 www.examples.com/v1/tasks는 할일 리스트를 www.examples.com/v1/tasks/2는 할일 중에 id값이 2인 할일의 상세 정보를 알려준다는 것을 유추 가능하다. 

       URI는 리소스 자체를 전송하는 것이 아닌 리소스의 표현을 전송한다. 사과 자체를 전송하는 것이 아닌 사과를 묘사한 표현을 전송하는 것이며 이렇기 때문에 더욱더 자유롭게 보낼 수 있고 사과가 바뀌었을 때 영향을 최소한으로 받을 수 있다. 즉 진정한 의미의 API는 API의 내부 로직이 수정이 되든 업데이트가 생긴다 하더라도 클라이언트의 수정은 최소화 시켜야 한다는 것이다. (예를 들어 API가 DB의 값을 그대로 다 response해버리는 경우 추후 database scheme이 변경되어버리면 클라이언트 쪽에서 수정을 해줘야하는 상황이 발생할 수 있다.)

         5) Layered System : 1번 특징에서 이어지는 내용이다.

         6) Code On Demand (Optional)

 

  즉 REST API 란 서버를 더 서버답게, 웹을 더 웹답게 쓰기 위한 하나의 가이드 라인이며 위의 6가지가 그 가이드라인의 내용인 셈이다. 즉 하나의 라이브러리처럼 그냥 import해서  그대로 써서 만드는 것이 아닌 위의 내용들을 준수하며 내가 만들어 나가야 하는 그런 추상적인 개념인 듯 하다. 그렇기 때문에 내가 계속 만들어보고 활용하면서 정말 REST API에 가까운 코드를 만들어내는 것이 바람직 할 듯 하다