REST(REpresentational State Transfer)
: HTTP를 이용해 통신하는 네트워크상에서 정한 약속
: 인터넷, 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 설계 형식
: 자원을 대표하는 단어 or 식별자로 자원의 상태를 전송하는 방법
*자원 : 인터넷에서 제공하고 얻을 수 있는 모든 것
: 자원을 이름으로 구분하여 상태를 전송하는 방법
REST가 필요한 이유?
웹의 독립적인 운용과 발전의 측면
1. 하위 호환(기존의 약속들)을 깨뜨리지 않고 독립적 발전
REST 설계 조건 : REST가 되기 위한 필요충분조건
1. Server - Client
2. STATELESS
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand
API ( Application Program Interface )
Request와 Response를 오가는 구조화된 데이터
특정 형식으로 주고 받겠다는 '형식' = API 문서
REST API
: REST 아키텍쳐 스타일을 따르는 API
REST API를 제공하는 웹서비스를 Restful하다고 이야기 한다.
REST 설계 조건을 잘 지키는 API
HTTP(GET, POST 등)로 CRUD를 구현할 수 있는 API
현대의 대부부늬 API가 REST 설계 원칙을 잘 지키고 있을까?
NO. 비슷하게 만들고 있긴 하다. 왜냐하면 JSON을 이용한 통신이라서 그러하다.
JSON은 모든 태그가 만들어져 있는 것도 아니라, 만든 이가 정의하기 나름이기 때문에 그것만 봐서는 무슨 뜻인지 이해가 가지 않을 수도 있다.
JSON이 이 전에 어떤 링크를 타고 왔는지 이 다음 링크 상태 전이는 어디로 가는지 알 수 없다.
따라서, JSON만 봐서는 무슨 뜻인지 알 수 없기 때문에 REST의 초기 의도인 '하위 호환(기존의 약속들)을 깨뜨리지 않고 독립적 발전'에서 벗어나게 된다.
REST 설계 조건 : REST가 되기 위한 필요충분조건 중 하나인 Uniform Interface
이 중 3,4를 잘 지키지 못하고 있기 때문에 REST하지가 못하다고 한다.
3. 메세지는 그 하나만으로 모든 것이 설명되어야 한다.
JSON이 self-descriptive하기 위해서 Host 도메인, Content type 헤더, json 명세 등등 이 필요하다.
대부분의 restful들은 이런것들을 만족하지 못하는 경우가 있다. Content type도 없는 경우가 있고, 요즘 API들이 self-descriptive 하지 못하다고 이야기 한다.
4. 애플리케이션의 상태는 하이퍼링크를 이용해서 전이되어야 한다. 예측가능성과 투명한 정보 전이를 위해서 만들어진 원칙이다. 요즘은 하이퍼링크로만 이루어져야지 REST하다고 정의하는데 잘 지키고 있지 않다.
따라서, 현대 RESTful API 들은 self-descriptive하지 못하고, HATEOAS를 지키지 못하고 있기 때문에 엄밀한 의미에서는 REST가 아니다. 라는 말이 나온 것이다.
참고 : [Network] REST란? REST API란? RESTful이란?
'Server > django' 카테고리의 다른 글
[Django] View of DRF ( Django Rest Framework ) (0) | 2020.05.04 |
---|---|
[Django] JSON 직렬화 - Serializer (0) | 2020.04.28 |
[Django] JSON, Http Request & Method, Httpie (0) | 2020.04.23 |
[Django] CRUD (0) | 2020.04.16 |
[Django] 장고 기초 - AWS 배포하기 (0) | 2020.03.05 |