[web] Rest API와 Rest 개념 총정리

 

Rest API란 Rest 아키텍쳐 스타일을 따르는 API를 말한다.

 

그렇다면 Rest는 무엇인가?

 

Rest는 웹과 같은 분산 하이퍼미디어 시스템을 위한 아키텍쳐 스타일을 의미한다. 아키텍쳐 스타일이라고 함은 곧 제약조건의 집합을 의미하게 된다. 제약조건을 모두 지켜야 rest를 따르는 것이 되는 것이다.

 

그러면 Rest의 제약조건들은 무엇인가?

이는 아래와 같이 6가지의 아키텍쳐 스타일로 구성되어 있다.

- client-server

- stateless

- cache

- uniform interface

- layered syetem

- code-on-deman(javascript처럼 코드를 서버에서 클라이언트로 보내서 바로 실행가능하도록 하는 것을 말함)

 

http만 잘따라도 uniform interface를 제외한 제약조건들을 잘 지킬 수 있다. 여기서 문제가 되는 것이 uniform interface이다. 이를 잘 만족하지 못하는 경향이 있다.

 

uniform interface의 제약조건

- identification of resources

- manipulation of resources through representations

- self-descriptive messages

- hypermedia as the engine of applicatio state(HATEOAS)

이 중 하위 2개의 요소가 잘 지켜지지 않는다.

 

self descriptive

massage의 내용 그 자체만으로 온전한 massage해석이 가능한 것을 의미한다. json는 self descriptive가 불완전 하다. self descriptive는 확장 가능한 커뮤니케이션을 가능하게 한다. 서버가 변하거나 클라이언트가 변하더라도 massage는 self descriptive하게 된다.

 

Hateoas

애플리케이션의 상태는 Hyperlink를 통해 전이되어야 한다는 것이다. link는 동적으로 변경가능하다. 서버에서 링크가 바뀌어도 클라이언트 측에서는 전혀 문제가 되지 않는다. late biding을 제공한다고 하는데, 이는 어디서 어디로 전이가 가능한지 미리 결정되지 않으며, 어떤 상태로 전이가 된 후 그 다음 전이될 수 있는 상태가 결정된다는 것이다. 쉽게 말해, 어떤 웹페이지에 접속하고 나서야 그 다음에 접속할 수 있는 하이퍼링크를 타고 또 다시 다른 페이지로 이동 가능한 것이다. 이러한 특성은 서버가 동적으로 링크를 바꿀 수 있게하여 독립적인 진화를 가능케 한다. html의 경우 <a>태그를 통해, json의 경우 Link헤더를 통해 Hateoas구현이 가능하다.

 

그렇다면 이렇게 잘 지켜지지 않는 uniform interface가 왜 필요한 것인가?

바로 독립적인 진화를 위해서다. 서버와 클라이언트가 각각 독립적으로 진화할 수 있으며, 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없게 된다. 예를 들면 크롬이라는 브라우져에서 웹 페이지를 변경한다고 하더라도 우리는 크롬을 새로 업데이트 할 필요가 없다. 웹페이지의 uri가 바뀌든 내용이 바뀌든 간에 항상 잘 접속이 된다. 심지어 http, html 명세가 변경되어도 웹은 잘 동작한다.

 

모바일 앱의 경우에는 이것이 잘 적용되지 않는다. 앱의 서버 기능이 변경된다면 클라이언트 쪽에서 변경을 해야 하기 때문에 업데이트가 필연적으로 발생하게 된다. REST를 따르지 않기 때문이다. 반면 웹 브라우저는 이런일이 생기지 않는다. 물론 이러한 독립적 진화가 가능하게 된 것은 웹 브라우저, 서버 개발자들의 엄청나게 피,땀흘린 노력의 산물임은 분명하다.

 

Rest는 웹의 독립적인 진화를 위해 만들어졌고 웹은 독립적인 진화가 가능하게 되었다.

---

REST API

Rest API 또한 Rest 아키텍쳐를 따라야 한다. 하지만 오늘날 Rest API는 rest를 지키지 않는 경우가 대다수 이다. 말로만 rest API라고 하는 API가 허다한 것이다. 그렇다면 왜 rest를 지키지 않고 rest API라고 하는 것일까?

api는 rest가 잘 되지 않기 때문이다.

웹 페이지와 api모두 http Protocol을 사용한다. 하지만 전자는 사람-기계/ 후자는 기계-기계의 커뮤니케이션을 하므로 media Type이 다르다. 웹페이지의 경우 html을 api의 경우 json을 사용한다. 바로 이점이 api가 rest를 지키지 쉽지 않는 이유이다. json은 하이퍼링크가 정의되어있지 않으며 self-descriptive가 불완전하기 때문이다.

 

self-descriptive 구현

1. Media type을 정의한다.

미디어 타입을 하나 정의하는 방법은 매번 media type을 정의해야 하는 단점이 있다.

2. Profile

의미의 대해 정의한 명세를 작성한 후 Link헤더의 rel에 profile relation으로 해당 명세를 링크한다.

단점 : 클라이언트가 link헤더와 profile을 이해해야 하며 링크를 이용하기 때문에 Content negotiation이 불가능하다.

 

Hateoas의 구현

1. Data에 다양한 방법으로 링크를 정의한다. 직접 링크를 정의하는 것이 불편하다.

2. http헤더로 link를 표현한다.

 

---

정리

- 오늘날 대부분의 rest api는 rest를 따르고 있지 않다.

- rest의 제약조건 중 특히 self-descriptive와 Hateoas를 잘 만족하지 못한다.

- rest는 긴 시간에 걸쳐 진화하는 웹 애플리케이션을 위한 것이다.

- rest를 무조건 따라야 할 필요는 없지만 따른다면 self-descriptive와 Hateoas를 만족시켜야 한다.