스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 섹션2. 서블릿

 

앞에서 봤던, 서버가 웹에서 응답을 받을 때 request용 인스턴스, response용 인스턴스를 만들고 응답은 response를 통해 한다는 것이 이 코드 부분이다.

응답코드의 헤더와 body로 저렇게 해주면 알아서 HTTP OK 200 ....을 작성해주는 것.

 

스프링 안에는 톰캣이 내장되어 있으므로 스프링이 톰캣을 실행하고, 스프링에 servlet 한번 스캔하게 설정했으면 servlet 관련 클래스들을 생성해준다. 그 뒤 활용함.

 

디버그를 설정하면 어떤 헤더를 만드는지 직접 볼 수도 있다. 물론 크롬에서 개발자모드로도 가능.

 

 

 

HTTP 요청, 응답 헤더와 내용을 뜯어볼 수도 있다. servlet의 request에서 get하면서 가져올 수 있다.

 

HTTP에서 서버로 요청하는 방법은 3가지가 있다. GET에서 query로 전송하는 것, HTML form 형식의 POST로 전송하는 것, JSON같이 데이터만 담아서 POST로 전송하는 것.

query를 통해 GET으로 전달하는 모습이다. 서버에선 파라미터 조회로 알아서 받게된다.

 

html의 POST로 전송하는 방법. query와 같은 데이터를 넣어서 같은 결과를 내지만, 주소창에 query문 없이 쌩 /만 있다는 특징이 있다. html의 POST로 전송하는 경우, 헤더에서 Content-type이 application/x-www-form-urlencoded 이다. postman에서도 저 헤더 그대로 전송 가능. 사실 application/x-www-form-urlencoded의 경우 똑같이 query로 날라와서 받을때도 getParameter로 받아야 한다.

 

 

data api형식으로도 보낼 수 있는데, Content-type 형식이 text/plain이나 application/json으로 다른 것이다.

특히 json의 경우, 이미 많이 보편화되어있기 때문에 json을 encoding, decoding은 왠만하면 있고, 그냥 JSON 형식인걸 알아내서 바로 클래스에 넣어주기도 한다.

 

 

응답 HTTP의 경우 response를 이용해 정해준다. 이러니 저러니 하지만 결국은 약속된 HTTP 형식을 따르게 하는 것을 더 편리하게 만들어주는 것 뿐이다.

중요한건 위 request처럼 Content-Type에 따라 브라우저해서 해석하는게 다르다. 진짜 결국은 사전에 약속한 HTTP 형식을 이용해서 데이터를 주고받고 웹 브라우저는 이를 약속한 유형으로 준다고 가정하고 잘 로직을 짠다.

당연히 많이 쓰이는 것이었을 테니 set말고 편리하게 해줄 수 있다. 특이한건 redirect의 경우 이론에서 약속했던 302번 status code와 Location으로 어디로 가야할 지 보낸다는 것.

 

 

밑은 Content-Type을 어떻게 하느냐와 반환 값도 어떻게 하느냐에 따라 웹 브라우저가 해석하는 차이.

 

이 html의 경우 좀 생각해볼 수 있는데, 만약 Content-Type을 html이 아닌 plain으로 하면 저 상태 그대로 출력되어 보여준다는 점이다. 서버가 HTTP Header의 Content-Type을 html로 지정해주었기 때문에 브라우저가 html로 인식하여 해석하는 것.