[세미나 리뷰] 사실 우리가 RESTful하다고 여기는 것은 사실 진정한 의미로 RESTful하지가 않아요.

🤔 왜 이런 글을 쓰게되었어요?

때는 바야흐로 2022년 8월 13일 새벽 3시, 포트폴리오를 깎고(?)나서 잠에 들려고 침대에 누워 유튜브를 보는데 알고리즘으로 다음의 영상이 잡혔습니다. 그리고 이 영상은 저에게 큰 충격을 주었습니다. (그냥 자려고 했었는데 이 영상 보다가 새벽 4.5시에 잔건 안 비밀)

그런 REST API로 괜찮은가?

제가 이전까지 생각해왔던 RESTful 하다의 의미는 아래와 같았습니다.

👉 client-server 구조로 되어있는 환경에서 uri가 리소스의 상태, 조작 행위들이 충분히 설명될 수만 있다면 그건 RESTful한 API야!

위에 언급한 제 생각이 아마도 개발자들 사이에서 흔히 통용되는 RESTful API의 정의였을 겁니다. 아마도?

그런데 REST를 최초 설계한 Roy Fielding 이라는 분께서는 그렇게 생각을 하시지 않고, 너네가 REST라고 하는 것은 사실 REST하지가 않아! 라고 하고 다니신다고 합니다. 무엇이 문제일까요?

🚀 우선 REST가 탄생한 배경부터 알아볼 필요가 있습니다.

우선 1991년으로 되돌아가봅시다. 1991년에는 Web이란게 최초로 등장하였고, 정보들을 HyperText로 표현하여 인터넷 상에서 정보를 전달하고자 하였습니다. 따라서 당시의 web은 아래의 것들을 사용해서 정보를 전달하였습니다.

• 정보의 표현 형식: HTML
• 식별자: URI
• 정보를 전달하기 위한 프로토콜: HTTP

이 때 당시에 사용하던 HTTP의 버전은 HTTP/0.9 였습니다. 그리고 1994년부터 HTTP/1.0의 개발이 시작되었습니다.

이 때 Roy Fielding 이라는 사람은 아래를 고민하기 시작하였습니다.

🤔 How do I improve the HTTP without breaking a web?

위의 고민 끝에 2000년, Roy Fielding은 자신의 박사논문으로 REST 라는 것을 발표하였습니다.

🤔 REST란 무엇일까?

우선 REST가 무엇인지 알기 전에, REST의 정확한 fullName부터 알아봅시다.

REST: REpresentative State Transfer; a way of providing interoperability between computer systems on the internet

위의 말을 직역하자면, REST 란 컴퓨터 시스템 간에 상호운영성을 제공하기 위한 수단이라는 것입니다. 이것만 보고 모르겠는데요?

그리고 Roy Fielding에 의하면, REST가 컴퓨터 시스템 간에 상호운용성을 보장하기 위해 아래의 조건들을 만족해야한다고 합니다.

1. Client-Server 구조의 아키텍처
2. Stateless
3. Cache
4. Uniform Interface
5. Layered system
6. Code-on-demand (optional)

사실 저희는 서버 코드를 작성하면서 4번의 Uniform Interface를 제외하면 잘 지키고 있습니다. 6번의 Code-on-demand의 경우 JavaScript 기반의 프론트 서버에서 잘 적용이 되는 사항인데, 이는 Server 측에서 정보를 제공하면 client 측에서 이를 렌더링할 수 있어야한다라는 것입니다.

이건 좀 논외 사항인데요, 사실 Java또한 code-on-demand를 보장하려던 노력이 존재합니다. JVM의 내부 구조를 잘 들여다보면, 연산을 Stack frame 기준으로 진행시키는 것을 알수가 있는데, client마다 CPU의 register frame이 다르기 때문에 그 문제를 해결하고 client 측에서 자바 코드를 해석할 수 있도록 만들려고 하였던 노력의 일환이었습니다.

이제 4번 사항인 Uniform Interface에 대해서 알아봅시다. Uniform interface를 보장하기 위해서는 아래의 4가지가 보장이 되어야한다고 합니다.

1. Identification resources (리소스의 식별이 uri를 통해 잘 이루어지면 된다.)
2. Manipulation of resources through representatives. (리소스의 조작 행위가 식별자를 통해서 잘 표현이 되면 된다.)
3. Self-descriptive messages
4. Hypermedia As The Engine Of Application State (HATEOAS)

사실 저희는 Uniform Interface 중에서 1, 2번은 정말 잘 지키고 있습니다. 아래의 사례를 통해서 말이죠.

GET https://any-school.org/classes/3/members?id=7

위의 uri 만으로도 저희는 any-school의 3반에서 7번 학생 을 대상으로 탐색을 하고싶은 거구나! 라고 uri만 보고도 식별이 가능합니다.

그런데 이제 문제는, 3번과 4번 사항을 저희는 지키지 않고 있다는 것입니다.

각각의 의미를 되짚어봅시다.

1️⃣ Self-descriptive messages

위의 의미는, 메시지는 스스로의 모든것을 알아서 설명이 가능해야한다 라는 뜻입니다.

예를 한번 들어볼까요?

👉 첫번째 예시

GET HTTP/1.1
HOST: www.any-school.org

위의 사례의 경우, 목적지가 명시되어있는 응답이 아니기 때문에 Self-descriptive하지 못합니다.

👉 두번째 예시

HTTP/1.1 200 OK
Content-Type: Application/json
Body: {
	"op": "remove", 
    "path": "/a/b/c"
}

위의 사례 또한 Self-descriptive하지 못합니다. 왜냐하면 위의 응답만 보고는 해석을 할 수가 없기 때문입니다. 따라서 메세지가 스스로 자신을 설명하지 못하는 상황입니다.

만일 위의 응답이 Self-descriptive하기 위해서는 json을 해석하는 방법이 추가되어야합니다.

👉 올바른 예시

HTTP/1.1 200 OK
Content-Type: Application/json+patch json
Body: {
	"op": "remove", 
    "path": "/a/b/c"
}

이게 맞나 모르겠네...

다음으로 넘어갑시다.

2️⃣ HATEOAS

HATEOAS에 대해서는 저도 잘 모릅니다만, Application의 상태는 Hyperlink를 통해서 전이되어야한다 라는 의미라고 대충 알고 있습니다.

그러나 우리가 RESTful API를 설계하면서 이걸 신경쓸까요...? 저는 적어도 저걸 지키지 않습니다.

🤔 REST를 지키는데 왜 uniform interface를 굳이 지켜야하죠?

다시 Roy Fielding의 고민으로 돌아가겠습니다.

🤔 How do I improve HTTP without breaking a web?

그리고 Roy Fielding은 REST를 제시하면서 아래의 말을 덧붙였습니다.

👉 Client와 Server의 상호 독립적인 진화를 위해서는 REST를 정확하게 지킬 필요가 있다.

따라서 Uniform Interface까지 지켜줘야만 Roy Fielding이 제시하는 Client와 Server 사이의 상호독립적인 진화가 가능해진다는 것입니다.

🤔 그러면 우리는 Roy께서 말한거를 모두 지켜야해요?

사실 꼭 그렇지는 않습니다. Roy Fielding께서는 아래의 말도 덧붙였기 때문입니다.

👉 만일 당신이 시스템을 잘 통제하고 있어서 Server와 Client를 상호 독립적으로 진화시키지 않아도 괜찮다거나, 혹은 당신이 시스템의 진화에 관심이 없다면 REST는 지킬 필요는 없습니다.

그런데 문제는, Roy는 Uniform Interface를 지키지 않는데도 REST라고 부르는 것에 대해서 아주 극대노를 하고 계신다는 것입니다.

그러면 저희는 선택을 해야합니다.

1. 지금부터라도 Uniform Interface를 모두 지키면서 Roy의 조건을 맞춰주자!
2. 아니야...나는 REST를 지키지 않고, REST라고도 안 부르고 HTTPful API라고 부를래
3. 나의 API가 진정한 의미의 RESTful API는 아닌거 알아. 그런데 나는 그래도 RESTful이라고 부를래!

우리의 개발자들은 어떤 선택지를 선택했을까요? 재밌게도 Microsoft마저 3번의 노선을 채택했습니다. Roy가 극대노 하든말든 몰라요 ㅋ

따라서 정확한 의미의 REST는 아니겠지만, 일반적으로 개발자들 사이에서 통용되는 RESTful의 정의는 아래와 같을겁니다.

👉 Client-Server 구조이며 무상태 계층화 아키텍처를 따르고, URI를 통해서 리소스의 조작 방식, 그리고 리소스의 상태를 표현해줄 수만 있다면 충분히 RESTful하다고 볼수있다.

🌲 Reference

그런 REST API로 괜찮은가?