손영배 블로그 누구나 쉽게 이해하고 습득하기
그런 rest api로 괜찮은가 본문
REST
REpresentational State Transfer 전혀 모르겠다.
무슨 말인지 전혀 모르겠다.
REST가 나오게 된 역사.....
Q: 어떻게 인터넷에서 정보를 공유할 것인가?
A: 정보들을 하이퍼텍스트로 연결한다.
표현 방식 : HTML
식별자 : URL
전송방법 : HTTP
HTTP/1.0(1994-1996)
"How do I improve HTTP without breaking the Web"?
어떻게 하며는 Web를 망가트리지 않고 HTTP를 발전 시킬 수 있을까?
해결책 -> HTTP Object Model -> REST(1998)
API
XML-RPC(by Microsoft) -> SOAP
Salesforce API 공개
REST 승리
REST API : REST 아키텍쳐 스타일을 따르는 API
REST : 분산 하이퍼이디어 시스템(예 : 웹)을 위한 아키텍쳐 스타일
아키텍쳐 스타일 : 제약조건
독립적 진화
- 서버와 클라이언트가 각각 독립적으로 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
- REST를 만들게 된 계기 : "How do I improve HTTP without breaking the Web."
웹
- 웹 페이지를 변경했다고 웹 브라우저를 업데이트할 필요는 없다.
- 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요도 없다.
- HTTP 명세가 변경되어도 웹은 잘 동작한다.
- HTML 명세가 변경되어도 웹은 잘 동작한다.
상호운용성(interoperability)에 대한 집착
- Referer 오타지만 안 고침
- charset 잘 못 지은 이름이지만 안 고침
- HTTP 상태코드 416 포기함(I'm a teapot)
- HTTP/0.9 아직도 지원함(크롬, 파이어폭스)
그런데 REST API는?
- REST API는 REST 아키텍쳐 스타일을 따라야 한다.
- 오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
정리
- 오늘날 대부분의 "REST API"는 사실 REST를 따르지 않고 있다.
- REST의 제약조건 중에서 특히 Self-descriptive와 HATEOAS를 잘 만족하지 못 한다.
- REST를 긴 시간에 걸쳐(수십년) 진화하는 웹 애플리케이션을 위한 것이다.
- REST를 따를 것인지는 API를 설계하는 이들이 스스로 판단하여 결정해야 한다.
- REST를 따르겠다면, Self-descriptive와 HATEOAS를 만족시켜야 한다.
- Self-descriptive는 custom media type이나 profile link relation 등으로 만족시킬 수 있다.
- HATEOAS는 HTTP헤더나 본문에 링크를 담아 만족시킬 수 있다. - REST를 따르지 않겠다면, "REST를 만족하지 않는 REST API"를 뭐라고 부를지 결정해야 할 것이다.
- HTTP API라고 부를 수도 있고
- 그냥 이대로 REST API라고 부를 수도 있다.(roy가 싫어합니다.)