RESTful API에 대해 제일 잘 설명하고 있다고 하는 youtube 영상인
그런 REST api로 괜찮은가? 링크를 보고 오는 것으로 대체하겠다!
끝
.
.
.
.
.
.
.
이라고 하면 좋겠지만 내 공부를 위해 보고 난 후 영상에 대한 간략한 요약을 적겠다.
RESTful API
짧게 말하자면 우선
두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
라고 할 수 있다만.... 역시 와닿지 않는다.
REST는 무엇인가?
REpresentational State Transfer의 줄인말로 분산 하이퍼미디어 시스템(예: 웹)을 위한 아키텍쳐 스타일 이라고 할 수 있다.
2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.
여기서 아키텍쳐 스타일은 쉽게 제약조건들의 집합이라고 보면 된다.
아키텍쳐 스타일에는 6가지의 종류가 있다.
아키텍쳐 스타일Client-Server
state less
cache
Uniform interface
layered system
code-on-demand(optional)
(각 스타일에 대한 자세한 내용은 생략하겠다.)
위 제약조건 들을 지켜야 REST API라고 할 수 있다. 대부분의 오늘날 rest api 라고 불리우는 것들을 위 내용들을 잘 지키고 있다. 하지만 이중 Uniform interface 조건은 다들 잘 지키지 못하고 있다.
그럼 Uniform interface 의 제약조건을 보자
- identification of resource(리소스가 uri로 식별되야한다)
- manipulation of resources through representations(representation 전송을 통해서 리소스를 조작해야 한다 (post put get 과 같은 리소스 조작의 표현을 담아서 전송해야한다))
- self-descriptive messages (메시지는 스스로를 설명해야한다)
- hypermediz as the engine of application state(HATEOAS)(애플리케이션의 상태는 Hyperlink를 이용해 전이되어야한다)
이중 밑에 있는 진한 2개는 거의 대부분의 자칭 rest api 들은 지키지 못하고 있다.(위 두가지에 대한 자세한 내용은 다음에 작성하겠다.)
Uniform interface를 지켜야하는 이유
독립적인 진화
서버와 클라이언트가 독립적으로 진화해야 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
로이 필딩의 생각에 답이 있다.
"How do I improve HTTP without breaking the web" 웹을 망치지않고 HTTP를 개선하려면 서버와 클라이언트가 독립적으로 진화해야한 한다고 생각
그래서 우리는 Unifrom interface를 잘지켜야한다.
하지만 그러지 못하고 있지.........
만! 웹블라우저가 이를 잘 지키면서 돌아가고 있기 때문에 걱정하지 않아도 된다. 😄
API
간단하게 api도 설명을 하자면 API는 Application Programming Interface의 약자로
한 프로그램에서 다른 프로그램으로 data를 주고받기위한
방법
이고 따라서
RESTful API는
인터넷을 통해 두 프로그램 간 data를 주고받기위한 상호간의 약속(아키텍처 스타일)를 잘 지키는 방법
