HTTP프로토콜을 스프링 서버가 받는 과정(+HTTP 구조,Content-type)

먼저 HTTP프로토콜의 본질에 대해서 알아보자.

HTTP는 요청(Request)를 보내면, 그에 대한 응답(Response)을 돌려주는 규칙을 정의하는 프로토콜이다.

즉 HTTP프로토콜은 HTTP Request 와 Response라는 두 종류의 메시지로 통신한다.

 

• HTTP Request : 클라이언트가 서버에게 보내는 요청
• HTTP Response: 서버가 클라이언트에게 보내는 답장

 

1.HTTP 프로토콜 구조

그리고 Request든 Response든

HTTP 프로토콜은 크게 아래와 같은 3단계 구조로 나누어져있다.

• Start Line
• Headers
• Body

1-1. Start Line

그리고 Request의 Response의 차이는 Start Line에서 나타난다.

왜냐하면 Start Line은 해당 HTTP 메시지의 핵심 의도를 나타내는 곳이기 때문이다.

따라서, Request의 Start Line은 무엇을 어떻게 요청할 지에 대한 내용이 담겨 있다.

POST /users/login HTTP/1.1

• HTTP 메서드는 무엇인지(ex.POST)
• 경로는 어떻게 되는지 (ex.users/login)
• 프로토콜 버전은 어떻게 되는지(ex.HTTP/1.1)

Reponse의 Start Line은 요청에 대한 처리결과(상태코드)가 담겨있다.

HTTP/1.1 200 OK

• 이 응답은 어떤 HTTP 버전인지(HTTP/1.1)
• 요청 처리는 성공/실패 했는가(200 OK)

1-2.Header

Headers는 Body를 어떻게 해석할 지에 대한 내용이다.

Body의 데이터 형식은 어떠한지, 인증은 무엇인지, 캐시는 가능한지

Host: api.example.com
Content-Type: application/json
Authorization: Bearer xxx

 

1-3.Body

Body는 실제 우리가 보내는 데이터가 담긴다.

{
  "email": "...",
  "password": "..."
}

 

---

2.Header의 Content-type

Body에는 단순한 문자 바이트 덩어리들만 실려있을 뿐이다. 

실제로 그게 숫자든, 문자열이든, JSON이든, 파일이든 그냥 바이트일 뿐이다.

그래서 HTTP프로토콜의 Header에는 이걸 어떻게 해석할지 방법을 제시한다.

그것이 Content-Type이다.

HTTP 메시지의 Body가 어떤 형식(문법으로) 작성되었는지를 나타내는 것이다.

이 HTTP 메시지를 서버가 받든 다시 클라이언트가 받든 서버나 클라이언트가 이 헤더의 Content-type을 보고 메세지를 어떻게 해석할 지 파악하는 것이다.

 

---

3.스프링

3-1.HTTP 요청 수신

스프링(Spring MVC)가 어떻게 이 HTTP메세지를 받아들이는 지 좀 더 구체적으로 보자.

클라이언트로부터 HTTP 요청을 받으면 서블릿 컨테이너(Tomcat)은 이를 HttpServletRequest 객체로 감싸서

DispatcherServlet에 전달한다.

*Servlet은 HTTP 요청을 자바 코드로 처리하기 위한 표준 인터페이스고 그 구체적인 객체가 DispatcherServlet이다.

 

그리고 이 DispatcherSevlet 객체는 HTTP의 Start Line에 있는 요청URL과 HTTP Method를 기준으로 요청을 처리할 컨트롤러를 찾는다.

이후 Header의 Content-type을 보고 어떤 데이터 형식인지 파악한 다음 Body 어떻게 파싱할 것인지 결정한다.

이 때,  Content-type 데이터 형식을 파악한 후 파싱을 위해 스프링(Spring MVC) 내부의 처리 체계 중 하나를 선택한다.

3-2.HTTP 요청의 Body 파싱

• 1.Parameter 기반 경로
• 2.Multipart 처리 경로
• 3.MessageConverter 처리 경로

1.Paramater 기반 경로는

Content-type이 application/x-www-form-urlencoded나 URL파라미터면 처리하는 경로다.

이 경우, 서블릿이 미리 파싱한 Map<String,String[]> 과 같은 결과가 만들어지고 이 결과를 바탕으로 컨트롤러의

@RequestParam, @ModelAttribute같은 어노테이션이 작동될 수 있다.

 

2.Multipart 처리 경로는

Content-type이 multipart/form-data로 들어오는 것에 대해 처리하는 경로다.

이때는 MultipartResolver라는 것이 요청을 분해하여 텍스트 파트는 Map<string,string[]>으로

파일 파트는 MultipartFile객체로 생성한다..

이를 통해 @RequestParam(텍스트), @ModelAttribute, @RequestPart 어노테이션이 작동될 수 있고 또 MultipartFile로 받을 수 있는 것이다.

 

3.MessageConverter처리 경로는 

Content-type이 application/json으로 들어오는 것에 대해 처리하는 경로다.

이때는 HttpMessageConverter라는 것이 

ObjectMapper를 통해 요청 Body(JSON메세지) 전체를 자바의 한 객체로 파싱한다.

그래서  @RequestBody로 받을 수  있는 것이다.

 

즉, 우리가 흔히 컨트롤러에서 사용하던 이러한 어노테이션은 이미 파싱된 결과를 어떻게 꺼낼지에 관해 정의하는 역할이다.

 

---

 

이처럼, HTTP요청이 Spring에서 Content-type, 파싱 경로, 파라미터 바인딩을 거치는 구조를 이해하면

컨트롤러에서 어노테이션 실수로 인한 오류를 감이 아니라 논리에 의해 정확하게 해결할 수 있을 것이다.