그래서 Rest API가 대체 뭔데 (역사이야기)

🤔 쓰읍..그 API는 Restful 하지 않은데?

🤬 규칙 다 지켰구만. Restful API가 대체 뭔데? REpresentation State Transfer? 어디서 만든 표준인데?

🤔 그걸 묻는 것 자체가 Rest 하지 않네.

🤬 $#*%*#&%

 

 

🚩 인터넷의 역사

💭 인터넷은 언제 나온건가요?

- 세계 2차 대전이후 1960년, 미국 국방부는 기존 중앙에만 집중된 통신 체계를 개선하고자 한다.

- 미국 국방부는 중앙이 없더라도 통신이 가능한 전국적인 네트워크 인프라, 아파넷을 구성하기 시작했다.

- 1973년 TCP/IP 도입, 모든 컴퓨터를 한 통신망에 연결(International Network)한다는 의미로 Internet 이라 부르기 시작.

- 이 때 당시 인터넷은 군대, 대형기업, 기관처럼 특수한 곳에서만 사용할 수 있는 네트워크 통신망이었다.

 

OSI 7 Layer, TCP/IP 4계층은 언제 나오게 된거죠?

요약)
OSI 7과 TCP/IP는 크게보면 비슷하지만, 만들어진 목적과 만든 곳이 다릅니다.
- OSI는 하드웨어 제조사의 네트워크 표준을 위해 만들어짐. (하드웨어~소프트웨어)
- TCP/IP는 컴퓨터간 통신을 위해 만들어짐. (하드웨어 관심 X)

1. 최초의 인터넷은 1960년 미국 국방부의 통신시스템, 아파넷(ARPAnet)이 시초였습니다.
2. 옛날 네트워크 표준이 없을때에는, 장치를 만든 곳이 다르다면 통신이 불가능했습니다.
3. 이는 매우 불편하기에, 1970년에 표준화를 시작하여 1984년 ISO에서 네트워크를 위한 표준인 OSI 7 Layer를 발표합니다.
4. 최초의 TCP/IP라는 개념은 1974년 한 논문을 통해 등장합니다.
5. 1982년에 기존 아파넷에 사용하던 프로토콜(NCP)을 TCP/IP 4계층 모델을 만들어 대체합니다.
6. 아파넷은 1990년에 종료되었지만, 여기에서 개발된 TCP/IP 4계층 모델은 그대로 사용되고 있습니다.

OSI는 국제표준화기구에서 만든 만큼, 더 일반적이고 모든 네트워크 통신에 적용 가능한 규약입니다. 이 모델에 맞춰 네트워크 통신을 구성해 별 작업 없이 모두 통신 가능하게 하자! 라고 외치는 가이드라인입니다. (때문에 네트워크 장비 등에 많이 쓰이는걸 볼 수 있습니다. (L7 스위치 등))

TCP/IP는 현재의 인터넷 구성을 위해 나왔던 실용적인 성격의 모델입니다. 복잡한 프로토콜을 작성할 시에 OSI 모델을 따를 경우 각 계층들이 너무나도 세세하여 작업이 번거롭습니다. (당장 우리가 매일 쓰는 HTTP만해도 OSI 모델의 3개 계층을 넘나듭니다.) 이렇게 커다란 프로토콜 구성 시에 다양한 영역을 아우르며 유기적인 동작을 할 수 있도록 구성된 것이 TCP/IP 모델입니다.

이런 성격들 때문에, 보통 서비스 프로그래머다 하면 tcp/ip 모델을 훨씬 많이 접할테고, 네트워크 작업을 할 경우 osi 모델을 자주 접합니다.
https://www.guru99.com/difference-tcp-ip-vs-osi-model.html

TCP/IP vs OSI Model: What’s the Difference?

 

 

💭 웹서버와 WWW는 무엇인가요?

- 1980년, 스위스 입자연구소(CERN)에서 힉스 입자를 찾기위해 전세계 127개국, 12000명의 과학자들이 모이게 된다.

- 당시 비정규직 프로그래머인 팀 버너스리는 서류나 정보를 쉽게 공유할 수있는 프로그램을 만들고자 했었다.

 

- 거의 10년이 지난 1989년, 스위스 입자연구소에도 마침내 인터넷 네트워크 인프라가 설치되게 된다.

- 1990년, 팀버너스리는 HTML 형식의 문서를 사용하는 World Wide Web 이라는 프로그램을 개발하게 된다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

- 1990년 12월, 인터넷을 이용해 웹 서버를 만들고 WWW에서 네트워크 접속 가능한 첫 사이트(info.cern.ch)를 오픈했다.

당시 사용했던 WorldWideWeb 프로그램. 인터넷을 이용해 웹서버에 접속할 수 있었다.

 

 

💭 HTTP는 대체 무엇인가.

- 인터넷을 사용하는 [ 웹서버 + WWW ] 조합은 연구소에서 폭발적인 인기를 얻게된다.

- 1991년, 웹서버와 WWW 통신을 [ HTTP v0.9 ]라는 이름으로 문서화하고, 이 프로토콜을 표준화 한다.

말이 표준화지, 사용법은 이게 다였다. URL이나 헤더라는 개념은 당시에는 없었다.

 

- 이후 다양한 추가기능과 유연성을 추가하며 1996년 [ HTTP v1.0 ], 1997년 [ HTTP v1.1 ] 을 발표하게 된다.

- [ HTTP v1.1 ] 은 15년간 안정성을 유지하며 사용하게 된다. 현재 배우는 대부분의 개념은 이 HTTP v1.1를 의미한다.

- 스마트폰의 등장으로 네트워크 사용량이 크게 높아지자 2014년 [ HTTP v2.0 ], 2020년 [ HTTP v3.0 ]이 등장하게 된다.

 

 

💭 인터넷의 대중 보급

- 1990년 웹서버와 WWW라는 신박한 개념이 등장한 후, 돈 냄새를 맡은 인터넷 서비스 기업(ISP)에서 보급을 시도한다.

- 하지만 가정집에 네트워크 인프라(인터넷)을 구축하기에는 너무나 비용이 많이 들었다.

- 그래서 기존에 집집마다 있던 전화선에 추가적인 모뎀장치(Modem)를 달아 인터넷에 접속할 수 있도록 구성한다.
그래서 이 당시에는 인터넷을 사용하면 전화가 끊겨서 같이 사용할 수 없었다. 물론 인터넷 요금도 정말 비쌌었다.

- 이후 1994년, WWW보다 어썸한 넷스케이프가 나왔고 1995년 그 유명한 MS의 인터넷 익스플로어가 출시된다.

WWW는 웹 클라이언트의 시초였다. 이후 넷스케이프 -> 인터넷 익스플로어가 나온 것.

- 이렇게 시작된 인터넷이 어떻게 전세계적으로 연결되었는지 궁금하다면, 아래 글을 참고하도록 하자.

HTTP #1 네트워크의 동작원리

 

 

---

🚩 SOAP 와 REST API

SOAP와 REST 둘 다 서버-클라이언트 API 아키텍처라고 볼 수 있습니다.

네트워크에 데이터를 주고받을 때, 어떤 규칙으로 주고 받을 것인가?

 

💭 SOAP 아키텍처의 탄생배경

1996년, 기존에는 사람이 읽는 문서만 주고받았으나 이제 서버-클라이언트가 데이터를 주고 받을 일이 많아지게 됩니다.

 

네트워크 망을 새롭게 만들면 번거로운데.. 기존 HTTP랑 HTML을 이용해서 Object-Model 같은거 만들면 안될까?

➡ 2000년, Microsoft에서 XML-RPC 문법을 발표하게 됩니다. 이후 SOAP(Simple Object Access Protocal)로 개명합니다.
XML 은 eXtensible Markup Language 라고 해서, 기존 HTML(Hyper-Text Markup Language)을 확장한 문법입니다.

단순 문서가 아니라 [데이터] 또는 [서버의 특정 함수를 사용]을 요청한다고 해서 RPC(Remote-Procedure Call) 기술이라 불립니다. 

 

 

💭 REST의 탄생 배경

당시 대학원생이던 Roy T Fielding, 본인이 설계한 새로운 아키텍처(문법과 규칙)에 REST라는 이름을 붙이게 됩니다.
참고로 당시 Roy T Fielding은 연구실에서 HTTP 표준을 정리하는 작업을 하고 있었습니다.

• 1998년 대학원생은 Microsoft Research에 본인이 만든 REST 아키텍처를 발표합니다.
• 2000년 대학원생은 RESTful API에 대해 박사 논문으로 발표합니다.
• 기존 HTTP Method, Status Code등을 적극적으로 이용하고, 자원(Resource)에 고유한 URI을 할당해 사용합니다. 

REST는 기존 HTTP 기능을 그대로 사용하는 API 아키텍처 설계방법입니다.

 

초기에 Rest는 큰 관심을 받지 못했지만, SOAP가 워낙 구렸기에 코드가 깔끔한 Rest 방식이 뜨게 됩니다.

2004년, 같은 API 요청을 SOAP와 REST 방식으로 했을 때.

 

이후 아마존 AWS, Salesforce.com 같은 API 서버를 제공하는 대기업들이 REST를 선택하여, 인기는 급 상승합니다.

2006년쯤 REST가 역전하게 됩니다. 현재는 REST만 거의 사용하죠.

 

 

💭 그럼 REST API는 대학원생이 쓴 논문이 표준인가요?

- 2008년에 EMC, IBM, Microsoft가 함께 CMS를 표준화하면서 REST API에 대한 것을 문서화하기 시작합니다.

🤔 (Roy T. Fielding) : 저기서 만든건 내가 정의한 REST 아키텍처가 아닙니다. 지 마음대로 쓴거에요

 

- 2016년부터 매년 Microsoft가 REST API에 대한 표준 가이드라인을 제공하기 시작합니다.

🤔 (Roy T. Fielding) : 저건 REST API 아니라니까? Rest API는 (Hypertext) Message-Driven이어야해.

 

 

💭 그럼 대체 REST API가 뭔데

REST : 분산 하이퍼미디어(ex 웹)을 위한 아키텍처 스타일. 규칙과 제약조건

REST API : REST 따르는 API /  HTTP를 효과적으로 잘 사용하기 위한 규칙.

• 명확한 Client - Server 구조
• 기본적으로 Stateless 한 통신
• 자원의 위치를 기록하는 URI (Uniform Interface)와 HTTP Method의 사용

 

Roy T. Fielding는 URI가 Hypertext-Driven 이어야 한다고 말한다. 대부분의 REST는 아래 규칙을 잘 지키지 않는다.

• REST는 Self-descriptive Messages 여야 한다. (메시지만 보고 내용을 바로 알 수 있어야 한다.)

Content-Type, Link 같은 해석용 정보가 반드시 함께 적혀있어야한다.

• REST는 HATEOAS (Hypermedia as the engine of application state) 해야한다.
  쉽게 말해 어플리케이션의 다음 상태가 메시지에 포함되어야 한다. 서버에서 보내줘야한다.

웹 어플리케이션은 상태가 이런식으로 흘러간다.

이런식으로 메시지에 현재 상태와, 다음 상태값이 정의된 걸 HATEOAS 하다고 말한다.

 

 

💭 이렇게까지 강조하는 이유

Roy T. Fielding가 이러한 기능을 강조하는 이유는, REST를 처음 만들게 된 계기를 보면 쉽게 이해할 수 있다.

서버의 기능이 변경되어도, 클라이언트를 업데이트 할 필요가 없는 것이 REST한 설계라고 정의했기 때문.

HTTP를 수정하면 기존 웹이 호환이 안될거같은데.. 그걸 유지하면서 하는 방법은 없을까?
➡ 그래서 탄생한 것이 REST API 설계방법 ("How do I improve HTTP without breaking the Web")

웹의 상태 전이(링크)는 바뀔 수 있다. 이는 클라이언트에 있는게 아니라 서버가 제공(HATEOAS)해야 호환성을 유지하면서 변경할 수 있는데, MS 같은 곳에서 정의한 REST 표준은 그렇지 못하다.

 

 

---

🚩 그럼 REST는 만능인가요

💭 아니요.

REST 설계방법은 기존의 웹(HTTP)에 좋은 영향을 많이 끼쳤습니다.

사실 REST를 만든 사람이 대학원시절 HTTP 표준을 만들었답니다 ㅋㅋ..

하지만 REST는 별도의 기능없이, 기존 HTTP 메서드를 그대로 사용합니다. 표현력에 한계가 있습니다.

예를 들어 단건을 삭제할 때에는 Delete site.com/member 처럼 사용할 수 있지만, 여러 건을 삭제할 땐 애매합니다.

 

또한 영상이나 실시간 채팅처럼 커넥션 상태 값을 계속 가지고 있어야할 때는 HTTP를 사용하기 어렵습니다.

그래서 나온게 웹소켓! 처음만 HTTP로 연결하면, 이후 커넥션을 유지한다.

 

 

 

💭 2022년의 웹은 어떠한가

MS의 I.E가 깽판을 쳐놓긴 했지만, 구글의 Chrome이 나온 이후 표준이 확립되고 아래의 규칙들이 잘 지켜지고 있습니다.

• 웹 페이지가 변경되었어도, 브라우저를 업데이트 할 필요가 없다. (반대로 브라우저 -> 웹도 마찬가지)
• HTTP, HTML의 새로운 버전이 나오고 변경되어도, 기존의 웹은 잘 동작해야한다.
  
  

당연하다고 생각하고 사용하지만, 이를 유지하는 건 상당히 힘든 과정을 거쳐왔습니다.

• HTML5 초안을 만들어내는데 6년이 걸렸다.
• HTTP/1.1 을 완성하는데 7년, HTTP/2.0을 만드는데 총 15년이 걸렸다.
• 표준에 있는 오타 (Referrer 인데 referer 로 오타냄)을 하위 호환성때문에 아직까지 안고치고 있다.
• 많은 웹 브라우저에서 만우절 장난으로 구현한 416 코드를, 이후 확장성 때문에 416을 영구 결번으로 만들었다.

많은 브라우저가 실수한 기능은, 표준을 바꿔버린다. 확장성과 하위 호환성때문

구글 스토어에보면, 앱 업데이트 때문에 짜증난다는 리뷰를 자주 보셨을겁니다.

Chrome, Safari, Firefox 등을 사용하면서 브라우저 때문에 웹을 사용 못한다는 이야기를 들어본적 있는지 생각해봅시다.
물론 K-공공기관, K-은행은 인터넷 익스플로어가 아니면 사용못하긴 합니다..어.. 그래도 최근에는 많이 나아졌잖아요?

 

 

💭 그래서 어쩌라구요. REST를 완벽하게 만들어야해요?

꼭 REST를 완벽하게 따를 필요는 없다고 Roy T. Fielding 본인도 말합니다. 따른다고 무조건 좋아지는것도 아니니까요.

https://www.youtube.com/watch?v=RP_f5dMoHFc&t=1205s

 

엄밀히 말하면 REST API가 아니지만, 다들 신경쓰지 않고 REST API라고 부릅니다. ㅋㅋ 물론 Roy 본인은 싫어하겠죠
여담으로 MS의 오픈소스에 REST API를 다른이름으로 개명하자는 PR이 올라왔지만, 그럴 이유가 없다고 무시했답니다.

현재의 Rest API는 HTML이든 JSON이든 별도의 문서 없이 메시지를 이해하기 어렵습니다

 

 

 

📔 레퍼런스

모질라 - HTTP의 진화과정

Naver D2 - 그런 REST API로 괜찮은가

인프런- SpringBoot를 활용한 RESTful 웹 서비스 개발