HTTP Message

이전 포스트 (HTTP overview)에서 알아본 바와 같이, HTTP 기반의 웹 환경에서 요청과 응답의 데이터를 담고 있는 것이 HTTP message라고 하였다. 이번 포트스에서는 간단히 HTTP Message가 어떤 것인지 간단히 알아본다. 현재 HTTP/2가 등장했지만, 그 전에 HTTP message의 기본 구조를 알아보는 것이 목표이므로 HTTP/1을 중점으로 적는다.

HTTP Message는 ASCII로 인코딩된 요청과 응답의 데이터를 가지고 있다. 따라서
'HTTP Message = HTTP 요청/응답' 이라고 봐도 무방할 것 같다. 이 요청과 응답은 start-line과 header, body 세 가지로 구성되어 있다.

start-line

Chrome 같은 경우 개발자 도구 network에서 general 영역에 있는 항목과 같다. 크게 세 가지로 구분되어 있다.

• HTTP method : GET, POST, PUT, DELETE, PATCH 등 요청 시 사용된 method
• URL :
  요청하고자 하는 자원의 위치. HTTP method에 따라 요청 시 생성되는 URL의 형태가 달라질 수 있다. 예를 들어 GET의 경우 파라미터가 query string의 형태로 URL에 포함되어 요청이 생성되기 때문에 "http://abc.org?param=value" 와 같이 '?' 뒤에 지정해놓은 파라미터가 key:value 형태로 넘어가게 된다.
  
  POST의 경우 query string으로도 파라미터를 넘길 수 있지만, form data인 body의 데이터를 전송하게 되므로 URL는 보통 "http://abc.org/post" 와 같이 작성하게 된다.
  
  
• status code:
  응답의 start-line에 포함되어 있다. 요청을 수행한 결과에 따라 100 ~ 500번대로 나뉜다.
  
  - 100 : informational response. 한 번도 만나보지 못한 코드인데, 클라이언트의 추가작업이 필요하거나, 프로토콜의 변경 등이 필요할 때 발생한다고 한다.
  - 200 : successful response. 요청을 성공적으로 수행했을 때. 테스트까지 마치고 앱을 실행했을 때 나오면 뿌듯한 응답 상태.
  - 300 : redirection message. 요청한 URI의 자원이 변경되었거나 하는 경우 등장. POST의 경우 리소스를 만들어서 등록만 하는 method 이므로 redirection 해주지 않으면 302가 뜨는 것을 종종 볼 수 있다.
  - 400 : client errors. 유효하지 않은 URI나 method로 요청했을 경우 발생하는 상태. 오타이거나 파라미터를 추가 안했다거나 하는 단순한 실수가 많고 클라이언트 측 에러이므로 해결하기 비교적 쉽다.
  - 500 : server errors. 서버 측 문제. 개발을 연습하는 나의 입장으로는 500과 511을 종종 봤다. 500은 서버 내부 문제, 즉 Spring 쪽에서 코드를 잘 못 썼거나 예외 처리를 하지 않아서 runtime error가 난 경우이고, 511은 Spring security를 쓸 때 발생했었다.
  

Headers

해당 요청의 메타데이터들을 담긴 영역. 요청/응답의 주체 (요청의 경우 user-agent, host / 응답읭 경우 server)가 누구인지, 어떤 포맷으로 요청, 응답하는지 등에 대한 정보가 담겨 있다. 요청과 응답에 따라 조금 다르지만, 전반적인 구조는 같다.

request header

response header

서버 측에서는 header 정보를 읽어들여 이에 맞는 방식으로 데이터를 바인딩하거나 적절히 포맷된 데이터로 응답할 수 있다.

Body

요청/응답 마지막에 위치한 영역으로 payload의 영역과 같다. 다만 모든 요청/응답이 body를 가지고 있는 것은 아니다. 요청의 경우 GET 방식으로 자원의 URI만 요청한 경우에는 body가 없을 수 있다. 응답의 경우에도 마찬가지인데, POST 방식의 경우 리소스의 생성만 요청하므로 서버에서는 요청 수행 후 성공했다는 응답만 보여주면 된다. 그래서 보통 POST 수행 후에는 개발자가 임의로 redirect를 하는 방식으로 처리해준다.

Spring MVC를 통해 REST api를 구현할 때 @RequestBody나 @ResponseBody를 사용하는데 이 때 해당하는 부분이 이 HTTP body이다. 요청의 body를 받아들여서 바인딩하겠다는 것이거나 서버의 응답을 body로 하겠다는 의미이다.

references: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages