이 글은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 을 기반으로 작성된 글 입니다.
Http에 대해 많이 들어봤지만 제대로 다뤄본적은 없었다 이번 기회에 특징과 메소드를 정리해보자.
Http가 무엇이며 어떤 특징을 가지고 있는가?
Http 란?
HTTP - HyperText Transfer Protocol
직역하면 하이퍼 텍스트 전송 규약 이란 느낌인데 그냥 인터넷 상에서 데이터를 주고 받을 수 있게 해주는 규약이라 생각하면 된다.
주고 받을 수 있는 데이터
- HTML, TEXT
- IMAGE, 음성, 영상, 파일
- JSON, XML(API)
- 거의 모든 형태의 데이터 전송 가능
- 서버간에 데이터를 주고 받을때도 대부분 HTTP 사용
(현재의 http는 text 뿐만 아니라 우리가 아는 모든 데이터를 전송 가능하다 생각하면 된다.)
HTTP 특징
Http의 특징은 다음과 같다.
- 클라이언트 서버 구조
- 무상태 프로토콜(stateless), 비연결성
- Http. aptpwl
- 단순함, 확장 가능
클라이언트 서버 구조
-
클라이언트 서버 구조는 간단하게 클라이언트와
서버가 서로 요청(Request), 응답(Response) 을 하는 것을 의미한다.
(클라이언트 -> 서버에 응답 요청 후 대기)
(서버 -> 요청에 대한 응답)💁 -> 위와 같은 구조로 각각 클라이언트 (UI) - 서버 (비즈니스 로직) 에서 독립적인 발전이 가능하다.
무상태 프로토콜 (stateless)
늘 Http 특징에 대해 공부할때 가장 이해가 안가는 부분이였다. 예시를 통해 알아보도록 하자.
1. 상태를 유지하는 프로토콜 (stateful)
case 1)
- 👩🏻💻(손님1) : 불고기 버거를 살게요.
🧑🏻💻(점원1) : 몇개 살껀가요?
👩🏻💻(손님1) : 두개 살게요.
🧑🏻💻(점원1) : 카드, 현금 어떤걸로 결제 하실껀가요?
👩🏻💻(손님1) : 현금으로 할게요.
( 상태를 유지 )
case 2)
- 👩🏻💻(손님1) : 불고기 버거를 살게요.
🧑🏻💻(점원1) : 불고기 버거를 몇개 살껀가요?
👩🏻💻(손님1) : 두개 살게요.
🧑🏻💻(점원2) : 무엇을 두개 사신다는 거죠?
👩🏻💻(손님1) : ???
위의 케이스를 살펴보면 케이스 1은 점원이 중간에 바뀌지 않기 때문에 서버가 상태를 유지하는 경우에도 문제가 발생하지 않는다. 하지만 케이스 2를 보면 중간에 점원이 바뀌는 경우 문제가 발생하게 된다.
2. 상태를 유지하지 않는 프로토콜 (stateless)
case 1)
- 👩🏻💻(손님1) : 불고기 버거를 살게요.
🧑🏻💻(점원1) : 불고기 버거를 몇개 살껀가요?
👩🏻💻(손님1) : 불고기 버거 두개 살게요.
🧑🏻💻(점원1) : 불고기 버거 2개를 카드, 현금 어떤걸로 결제 하실껀가요?
👩🏻💻(손님1) : 불고기 버거 2개를 현금으로 할게요.
case 2)
- 👩🏻💻(손님1) : 불고기 버거를 살게요.
🧑🏻💻(점원1) : 불고기 버거를 몇개 살껀가요?
👩🏻💻(손님1) : 불고기 버거 두개 살게요.
🧑🏻💻(점원2) : 불고기 버거 2개를 카드, 현금 어떤걸로 결제 하실껀가요?
👩🏻💻(손님1) : 불고기 버거 2개를 현금으로 할게요.
위 케이스를 봤을때 손님이 요청을 할 때 말이 길어지는 단점이 생기지만 중간에 어떤 점원이 와도 요청을 처리 할 수 있다는 장점이 있다.
🖍 이처럼 stateful과 stateless의 큰 차이점은 중간에 다른 서버에 요청을 보내도 처리가 가능한가 아닌가 이다.
stateless 를 사용해 생기는 장점
-> 갑자기 손님이 많이 온다해도 어떤 점원이 주문을 받아도 처리가 가능하므로 서버 증설이 쉽다.
- 중간에 점원(서버)가 문제가 발생해도 다른 점원(서버)가 이를 처리 할 수 있다.
stateless의 한계
- 로그인과 같이 상태를 유지해야하는 경우는 사용자가 로그인 했다는 상태를 유지해야하므로 쿠키나 세션을 사용해 상태를 유지한다.
But 상태 유지는 최소한만 사용
비연결성 (Connectionless)
비연결성이란 말 그대로 서버를 연결한뒤 연결한 상태를 유지하지 않는 것을 의미한다.
- 이는 필요없는 연결을 끊어줌으로써 서버 자원소모를 줄일 수 있다.
-> 실제 서버에서 사용할때만 연결을 하니까 동시에 처리하는 요청에 대해 유리 하다.
ex) 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시처리는 수십개 이하로 매우 적다. ( 웹브라우저에서 연속해서 버튼을 누르지는 않음 )
단점
- TCP/IP의 3way hand shake를 매번 해줘야 하므로 시간이 증가 할 우려가 있음
- 웹 브라우저 요청시 html 말고도 JS나 CSS 파일도 함께 요청하게 된다. (지금은 Http를 지속 연결(Persistent connections로 해결)
HTTP 메소드
앞에서 Http의 특징에 대해 알아봤고 이제 HTTP 메소드에 대해 알아보자. 필자는 학부생때 배운 GET, POST가 HTTP 메소드의 전부인줄 알았지만 스프링을 공부하면서 더 많은 메소드들이 있다는 것을 알게 되었다...
HTTP API
회원 목록을 관리하는 API를 개발 한다 할때 초보 개발자들은 다음과 같이 URI 설계를 한다.
위의 설계를 보면 URI에 리소스 뿐만아니라 행위 까지 들어가 있다. 이는 옳은 설계 방법이 아니다. URI의 가장 중요한 것은 이름에서도 드러나있듯이 리소스 식별이다.
이때의 리소스는 그럼 무엇일까?
"회원을 조회하라." 이때의 리소스는 회원이다 그렇다면 조회하다는 무엇인가?
바로 행위를 나타내는 것이다. 리소스를 식별하는데 행위가 필요할까? 그렇지 않다. 그렇기 때문에 "조회하다", "등록" 등은 모두 빼주어야 한다.
🤔 그럼 이러한 행위를 어떻게 구분하나?
이를 해결하기위해 HTTP 메소드를 사용하면 된다.
HTTP 메소드의 종류
- GET : 리소스 조회
- POST : 요청 데이터 처리, 주로 등록에 사용
- PUT : 리소스를 대체 , 해당 리소스가 없으면 생성
- PATCH : 리소스 부분 변경
- DELETE : 리소스 삭제
GET 메소드
- 첫번째로 조회 요청을 한다.
- 서버에 도착
- 서버의 응답
GET 메소드는 주로 리소스를 조회할때 사용되며 서버에 요청시 쿼리 파라미터 or 쿼리 스트링을 사용한다. (추가로 GET 메소드도 바디에 메세지를 담아 보낼 수 있지만 이는 지원이 안되는 경우가 있기때문에 잘 사용하지 않는다.)
POST 메소드
-
메세지 전달
-
요청에 대한 비즈니스 로직 수행
-
응답
POST 메소드는 대부분 어떤 메소드를 사용해야 할지 막막할때 사용하면 된다. 이 메소드는 메세지 바디를 통해 서버로 데이터를 전달하고 서버는 이 데이터를 가지고 비즈니스 로직을 수행후 결과를 반환한다. (요청에 대한 처리를 서버가 한다.)
ex ) 새로운 리소스 생성, 게시판 글 등록, 비즈니스 로직 처리
✚ PUT, PATCH, DELETE
PUT : 리소스가 존재하지 않는다면 새롭게 생성하고, 원래 존재 한다면 이를 완전히 대체한다.
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
HTTP 의 속성
- 안전 : 호출해도 리소스가 변경이 되지 않는가
- 멱등 : 한본 호출 or 100번 호출시 결과가 같은가
- 캐시 가능 : 모든 웹 브라우저가 내부에 저장이 가능한가
