RESTful API란?

REST는 Representational State Transfer 의 약자로 자원 상태를 전달한다라는 의미로 볼 수 있다.

 

웹의 발전

웹은 1993년에서 1994년 사이에 일상적으로 사용되기 시작했으며 그 당시에는 웹 아키텍처에 대한 단편적인 설명만 있었고 웹 인터페이스 프로토콜에 대한 일부 표준에 동의해야 한다는 압력이 있었다. 이를 위해서 W3C와 IETF 그룹이 HTTP, URI, HTML 에 대한 형식적인 설명을 만들어나가는 작업을 진행했다. 이 과정중에서 Roy Fielding이 HTTP1.0, HTTP1.1 의 생성에 참여하였고 이 과정중에서 REST 아키텍처에 대한 내용을 설명하면서 퍼지게 되었다. 

 

REST API

Roy Fielding은 REST를 만들게 됐을 때 웹을 망가뜨리지 않고 HTTP를 발전시킬 수 있을지에 대해서 고민했다. 즉 기존의 것을 망가뜨리지 않으면서 계속해서 확장 해 나가는게 REST의 철학이다. 이 부분부터 시작해야 REST API의 진짜 장점을 알 수 있을것이다. 결론부터 말하자면 REST API는 서버와 클라이언트의 발전이 분리되어 호환성 문제를 없애는 것이다.

 

REST가 잘 지켜진 예시로 HTML이나 HTTP버전이 바뀌어도 웹 브라우저에서는 대부분 아무런 문제없이 잘 작동하는 것을 볼 수 있다. 이것은 웹 브라우저와 HTML, HTTP와 REST가 잘 지켜졌기 때문에 기존의 호환성을 유지하고 잘 사용하는 것이라 볼 수 있다. 

 

REST가 잘지켜지지 않은 예시로는 계속해서 앱을 업데이트 해야 사용할 수 있는 앱이다. 서버에서 개발을 해서 코드가 바뀌면 클라이언트에서 이를 맞춰주지 않으면 사용할 수 없게되는 것이다. 이 경우에는 서버와 클라이언트가 서로 의존하고 있기 때문에 REST하지 않다고 볼 수 있다.

 

REST API의 제한조건

REST api에서는 제한조건이 정해져있고 이 모두를 만족해야 REST하다고 볼 수 있다. 

 

1. Uniform Interface
2. Client-Server
3. Stateless
4. Cacheable
5. Layered System
6. Code on Demand(Optional)

 

HTTP통신을 하다보면 자연스럽게 2,3,4,5,6번은 자연스럽게 사용된다. 다만 1번의 Uniform Interface에서 잘 지켜지지 않는 부분이 있다. 

 

Uniform Interface

• Identificatino of resources - URI로 리소스를 식별시키면 된다는 것
• Manipulation of resources through representations - CRUD할 때 HTTP 메세지에 특정한 값을 보내야 한다. 대체로 POST, DELETE같이 일정한 규칙을 담아서 보내고 있음
• Self-descriptive messages 
• Hypermedia as the engine of application state(HATEOAS)

아래의 두 가지는 대체로 잘 지켜지지 않고 있으며 이 제한사항이 모두 지켜져야 REST하다고 볼 수 있다.

 

Self-descriptive message - 각 리소스 표현은 메시지 처리 방법을 설명하기에 충분한 정보를 전달해야 한다. 

Hypermedia as the engine of application state(HATEOAS) - 클라이언트는 애플리케이션 초기의 URI만 가지고 나머지 응용 프로그램 요청은 하이퍼링크를 이용해서 이동해야 한다.

 

위 두가지는 왜 잘 지켜지지 않을까?? 웹 페이지는 REST가 잘 지켜지고 있는 예시이다. 비교해서 살펴보면

	흔한 웹 페이지	HTTP API
protocol	http	http
커뮤니케이션	사람-기계	기계-기계
Media Type	HTML	JSON,XML

누가 정보를 받아들이냐에 따라서 크게 달라지는 것은 Media Type이다. HTML과 JSON 또는 XML로 받게 된다. 

	HTML	JSON
hyperlink	됨 (a 태그 등)	정의되어있지 않음
self-descriptive	됨 (HTML 명세)	불완전*

 

HTML에서는 모든 연결을 a태그를 통해서 하이퍼링크 이동한다. 그러나 json에서는 하이퍼링크 이동하게끔 명세되어 있는것이 없다.

또한 각 태그에 대한 설명이나 어떠한 문서인지에 대한 설명이 전부 명시되어 있다. 그러나 json은 어떻게 문법적으로 해석을 해야하는지는 알고있지만 태그 안의 내용이 무엇으로 이뤄져있는지에 대한 설명이 되어있지 않다. 

 

Content-type을 통해서 application/json이면 아래와 같이 해석을 할 수 있다 다만

{
"id" : 1
"name" :"강문식"
}

위와 같이 어떻게 해석해야하는지 문법적으로는 알 수 있지만 그 안의 내용이 id는 뭐고, name 이 무엇인지에 대한 설명이 되어있지 않다. 즉 명세가 되어있지 않다. 

 

반면 html의 Content -Type ,text/html 일 경우

1. HTTP 명세에 media type은 IANA에 등록되어 있다고 하므로, IANA에서 text/html의 설명을 찾는다. 

2. IANA에 따르면 text/html의 명세는 http://www.w3.org/TR/html 이므로 링크를 찾아가서 명세를 해석한다.

3. 명세에 모든 태그의 해석방법이 구체적으로 나와있으므로 이를 해석 할 수 있다. 

 

이렇기 때문에 self-descriptive message와 HATEOAS가 잘 지켜지지 않는 것이다. 

 

REST 하게 하려면?

그렇다면 우리의 상황에서 REST하게 하려면 어떻게 해야할까?

 

Self-descriptive message를 충족시키기 위해서는? 

방법1 - IANA에 명세를 등록한다. 

방법2 - profile -> Link에다가 id가 뭐고 title이 뭔지에 대한 정의한 명세를 작성한 위치를 달아서 보낸다(우리의 경우 eggwealth.kr/docs)  link헤더에 profile relation으로 해당 명세를 링크해야 한다. 다만 content negotiation이 안된다.

 

HATEOAS를 충족시키기 위해서는?

서버에서 발생할 수 있는 모든 경우의 api 호출을 같이 보내줘야 한다. eggwealth.kr이라는 초기값만 들고있으면 그와 관련된 api uri를 모두 보내줘야 한다. ex) 게시판에 들어갔을 때 그 게시판에서 다음페이지, 댓글달기, 댓글 삭제, 댓글 수정 등 이와 관련된 api uri를 서버에서 보내주면 클라이언트는 이 값을 참조하여 api를 실행시킨다. 

 

 

Self-descriptive message 와 HATEOAS를 왜 꼭 지켜야만 REST한가?

서버와 클라이언트가 상호 의존하게 되지 않기 때문이다. 

 

Self-descriptive message는 클라이언트가 이 문서만 보고서 모든것을 이해할 수 있게 되어 무엇이 바뀌든간에 언제나 해석이 가능하다.  

 

HATEOAS는 서버에서 URI를 동적으로 바꾸게 되는게 가능하다. 서버에서 eggwealth.kr/build/memo였던것을 eggwealth.kr/build/memong 으로 바꿨을 때 REST하지 않다면 클라이언트는 URI를 바꿔줘야 한다. 하지만 hateoas가 잘 지켜졌다면 서버가 저렇게 uri를 바꿔도 참조해서 사용하는 형태이기 때문에 동작하는데 문제가 생기지 않는다. 

 

 

그럼 꼭 REST를 사용해야 하는가?

꼭 사용하지 않아도 된다. Roy Fielding은 모든 상황이 통제가 가능하거나, 혼자서 개발할 경우에는 REST를 만드는데 굳이 시간을 쓰지 말라고 한다. 

 

즉 우리의 경우 서버와 클라이언트가 상호 가깝게 소통할 수 있고 빠르게 피드백이 가능한 상황이기때문에 REST 아키텍처를 무조건 따라야 할 필요가 없다. 현재 우리의 우선순위에서는 먼저 개발하고 발전시키는것이 더 중요하기 때문에 REST를 지키면서 시간을 소모하는것은 시간이 아깝다. 추후에 개발이 커지고, 클라이언트 업데이트를 최대한 줄여야 하는 상황이 처 해 있을 때 REST를 사용하는것을 고려하는것이 좋다.