1. Rest
1-1) Web(1991)
Q : 어떻게 인터넷에서 정보를 공유할 것인가?
정보들을 하이퍼텍스트로 연결한다.
→ 표현 방식 : HTML(HTML로 정보들을 표현)
→ 식별자 : URL(그 정보들의 식별자로 URL을 만듦)
→ 전송방법 : HTTP(HTTP라는 프로토콜로 전송방법을 해결함.)
1-2) HTTP/1.0(1994-1996)
Q : 어떻게하면 Web을 망가뜨리지 않고 HTTP를 한 단계 발전시킬 수 있을까?
해결책 : HTTP Object Model
→ 4년 뒤에 HTTP Object Model이 Rest(1998)로 발표 함.
→ 2년 뒤 Roy T. Fielding(로이 필딩)은 박사 논문으로 발표함.
⇒ 그의 논문이 오늘날 Rest의 정의가 됨.
1-3) API(Click)
1-3)-1. XML-RPC(1998) by Microsoft → SOAP(나중에 이 이름으로 바뀜)
→ 프로토콜의 일종으로서, 인코딩 형식에서는 XML을 채택.
→ 전송 방식에서는 HTTP 프로토콜을 사용하고 있다.
→ XML-RPC는 매우 단순한 규약으로서, 작은 데이터 형식이나 명령을 정의하는 정도로만 사용.
1-3)-2. Salesforce API(2000.2)
→ 인터넷에서 거의 최초로 공개된 API임.
SOAP을 이용한 Salesforce API Structure(Click)
→ 어떤 ID로 Object 하나를 가져오는 API의 요청 메시지가 이정도 분량임.
→ 굉장히 복잡함.
⇒ Salsesforce API는 복잡해서 인기가 없었음.
1-4)-3. Flickr API(2004.8)
→ SOAP과 REST라는 형태 두 가지로 API를 만들어 냈음.
1-5) Rest vs SOAP
→ 2006년, AWS가 자사 API의 사용량의 85%가 Rest임을 밝힘.
→ 2010년, Salesforec.com, Rest API를 지원하게 됨.
2. CMS(2008)
2-1) CMS
CMS(저작물 관리 시스템)를 위한 표준. EMC, IBM, Microsoft 등이 함께 작업
REST 바인딩 지원(데이터는 SOAP 형식이 아닌 텍스트 기반 형식으로 웹에서 전송 됨.)
2-2) Microsoft REST API Guidelines(2016)
URI는 https://{serviceRoot}/{collection}/{id} 형식이어야 함.
GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 함.
API 버저닝은 Major.minor로 하고 uri에 버전 정보를 포함시킴.
→ 사람들이 보기에 합리적이라고 생각했음.
⇒ 하지만 REST를 만든 로이 필 딩이 말하는 건
⇒ "REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것."
2-3) 뭐가 문제인 걸까?
2-3)-1. REST API
REST 아키텍처 스타일을 따르는 API
2-3)-2. REST
분산 하이퍼미디어 시스템(ex : 웹)을 위한 아키텍처 스타일
2-3)-3. 아키택처 스타일
제약 조건의 집합
→ 모든 제약 조건을 지켜야 REST를 따른다라고 할 수 있음.
2-4) REST를 구성하는 스타일
Client-server
Stateless
클러스터 또는 영구 스토리지에 데이터 또는 애플리케이션 상태를 저장하는 않는 애플리케이션임.
대신 데이터 및 애플리케이션 상태가 클라이언트에 유지되므로,
상태 비추적 애플리케이션은 확장성이 뛰어남.
Cache
- Uniform Interface(모든 제약 조건 중에 이 부분을 잘 만족시키지 못함)
Layered System
하부 층이 함수 및 기능과 상위 계층의 서비스를 지원하는 서비스를 제공하도록
계층적 배열로 계층화. 계속해서 증가하는 복잡성과 시스템은 여전히 제자리에 있는 구성요소를
사용하면서 전체 시스템 기능을 향상시키기 위해 계층을 추가하거나 변경하여 구축할 수 있음.
Code-On-Demand(Optional, 서버에서 코드를 클라이언트에게 보내서 실행한다는 의미)
→ 자바스크립트를 의미하는 거임.
→ REST는 아키텍처 스타일이면서 동시에 하이브리드 아키텍처 스타일이라고 말함.
⇒ 아키텍처 스타일인데, 동시에 아키텍처 스타일의 집합이기 때문.
2-5) Uniform Interface의 제약 조건(모든 제약 조건 중에 이 부분을 잘 만족시키지 못함)
→ Resource가 URI로 식별되면 된다.
→ Representation 전송을 통해 Resource를 조작해야 된다.
→ Resource를 저장, 수정, 삭제할 때 메시지에 담아 전송한다는 의미
→ 모든 REST API 중에 지키지 못하는 부분임.
→ Self-Descriptive라는 의미는 "메시지는 스스로를 설명해야 한다."
ex) HTTP 요청 메시지
ex) 응답 메시지
Hypermedia As The Engine of Application state(HATEOAS)
2-6) Uniform Interface의 사용이유
3. WEB
4. REST가 웹의 독립적 진화에 도움을 주었는가
5. 그렇다면 REST API는?
6. REST API를 구현하고 REST API라고 부른다면?
7. REST의 최종정리