0. 개요 1. HTTP라는 개념은 왜 나온걸까 2. HTTP? 그거 어떻게 생겨먹은 놈이니? 3. HTTP를 잘 쓴다는 건
0. 개요
a. HTTP 너무 어려워
사실 HTTP를 공부한다고 하면 좀만 깊게 들어가면 REST API니 뭐니 이해해야 할 게 산더미다.
b. 그냥 쉽게 이해하자
나는 그렇게 생각한다. HTTP는 인터넷이라는 도로를 운행하기 위해 지켜야 하는 도로 교통법 같은 것이며 개발자는 그 도로를 이용하는 운전수다. 도로를 이용하는 사람으로서 도로 교통법을 아예 모르면 안되지만 도로 교통법에 대한 구체적인 조항들까지 다 이해하고, 어떻게 해야 잘 준수할지를 고민하는 건 운전수로서의 역할이 아니라 법 학자들의 몫이다.
나는 오늘 본분에 최대한 벗어나지 않는 선에서 HTTP에 대한 기본적이지만 아주 중요한 설명을 해보려 한다.
1. HTTP라는 개념은 왜 나온걸까
a. 웹의 등장과 HTML
[그림2]. WEB의 창시자 팀 버너스-리
HTTP는 저 '팀 버너스 리' 라는 아저씨가 만든 '웹'이라는 개념에 중요한 3개의 요소 중 하나이다.
- HTML - HTTP - URL
저 버너스 리 라는 아저씨가 웹이라는 개념을 만들 때 제시했던 게 저 3가지다. 그 당시에 인터넷을 통해 주고 받던 문서들은 말 그대로 그냥 '문서'였다. 근데 저 버너스 리 아저씨는 '문서들 끼리 버튼 눌러서 왔다리 갔다리 할 수 있으면 재밌겠는데?'라는 생각을 했고 이를 실현하기 위해 HTML 이라는 마크다운 문서를 개발했다.
b. HTML 문서를 전송 하려면 ..
FTP(파일 전송 프로토콜), SMTP(메일 전송 프로토콜) ..
이제 새로운 마크다운 문서(HTML)를 만들었으니 이걸 어떻게 전송할지에 대해 고민을 해야 했는데, 당시에 있는 프로토콜들은 이 문서를 전송하는데 적합하지 않았다. 그래서 이 아저씨는 'HTML을 전송하기 위한 프로토콜을 만들자!'라는 생각을 했고 그래서 나온게 HTTP다.
2. HTTP? 그거 어떻게 생겨먹은 놈이니?
a. 백문이 불여일견이라고 한번 보자.
[그림3]. 개괄적인 정보와 요청, 응답 헤더 그리고 HTML ..
물론 요즘은 HTML 말고도 다양한 것들을 전송하지만, 위 www.naver.com에 대한 요청에서 볼 수 있듯이 HTML도 넘어오는데 이렇게 HTML이라는 마크다운 문서를 전송하기 위해 만들어진게 HTTP다.
b. 구체적으로 비교혀봐 ..
[그림4]. 인터넷에 떠돌아다니는 HTTP Request Spec과 실제 네이버 SPEC
얼추 비슷하다.
사실 이런 HTTP 헤더를 통한 설정을 어떻게 할 건지도 어느정도 제어할 수 있지만, 그건 필요할 때 찾아보면 되고 중요한 건 얘기 뭐하는 놈이냐는 거다. "HTTP 헤더는 내가 보내려는 메시지를 어떻게 다뤄야 하는지 설명 하는 놈"이다.
* 헤더에는 대충 아래 같은 내용들이 담겨있다. * # 메시지 바디의 내용, 메시지 바디의 크기 ,압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등..
3. HTTP를 잘 쓴다는 건
a. 사실 모호하다.
인터넷에는 많은 주장들이 있지만 어느 것 하나 명확한게 없다.
그래서 나는 그냥 HTTP Method만 잘 쓰자 라고 결론 지었다. HTTP METHOD는 POST, PUT, GET, PATCH 같은 것들이 있는데 관련 내용은 아래를 참고하자.
단, 이것도 서버 환경에 따라 문제가 생길 수 있으니 용도 맞는다고 막 쓰기 보단 기존에 돌아가는 시스템 컨벤션을 고려해서 작업해야한다. (개인 주관)
b. REST?
"REST라는 제약조건의 집합을 충족하는 API다." - 그것이 REST API -
REST는 아키텍처 스타일이고 아키텍처 스타일은 "제약 조건의 집합"을 의미한다. 따라서 REST API는 "REST라는 제약조건의 집합을 충족하는 API다."
어렵게 설명했는데 REST라는 건 로이 필딩이라는 아저씨가 HTTP 잘 쓰는 방법에 대해 연구한 논문에서 나온 개념이다. 이 아저씨는 여러 제약조건을 지켜야 한다고 주장했는데 그 중에서 내가 생각하는 중요한 부분은 stateless와 uniform interface이다. 관련 내용은 아래 첨부한다.
