[스프링 입문] 정적 컨텐츠와 MVC, 템플릿 엔진

웹을 개발하는 것은 크게 세가지를 포함한다.

 

1 정적 컨텐츠 static contents - 순수 HTML 등

2 MVC - jsp, php 등의 템플릿 엔진, 순수 HTML 아니고 동적으로 변형한 녀석들. 이걸 스프링에서는 MVC로 표현.

3 API

 

 

 

▶ 스프링에서 static을 다루는 건 쉽다.

 

앞서 main > resources > static 폴더가 존재한댔는데, 거기에다가 우리의 static 파일 넣어주면 된다.

만약 hello-static.html 파일이라면, 기존의 URL의 끝에 해당 파일 이름(~/hello-static.html) 넣어주면 된다.

매우 easy peasy.

 

이렇게 진행되는 과정은 다음과 같다.

서버는 들어온 요청이 정적에 대한 요청인지 동적에 대한 요청인지 알 수가 없기 때문에, 뭐든 간에 일단 tomcat이 받는다.

tomcat이 controller 쭉 찾아보다가 컨테이너에 해당 내용이 매핑되는 컨트롤러가 없다 -> 그 다음으로 resources 뒤지고, 거기서 해당 파일을 찾아서 반환해준다. 동적 컨트롤러 확인 우선 -> 정적 페이지 확인 이 순서라고 생각하면 된다.

 

예전의 PHP나 JSP는 MVC가 아니라 뷰 하나에 몰빵된 방식이었다. 모델 1이라고 부르기도 하는데, 요새는 MVC로 거의 대체된다. 플밍을 할때 각각의 파트가 관심사를 세분화하고, 관심을 집중해야 한다. View는 렌더링에 집중하는 방식이고, Controller는 뒤에서 돌아가는 방식이고, Model은 데이터 및 비즈니스 로직, 그리고 상태 관리.

 

 

 

▶ Controller에서 진행한 결과물을 Model에 집어넣는다고 생각해도 될 것 같다.

 

 

지난번 방식에서 좀 더 업그레이드된 모습인데, 파라미터가 추가됐다. RequestParam을 통해 name이라는 파라미터를 요청하고, 그걸 name이라는 String에 집어넣어줌. 근데 이 name은 어디서 날아오는 거지?

 

알고보니,,, ~ /hello-mvc?name=king 이런 식으로, 매핑되는 주소 뒤에 ? {변수이름}=뭐시기 이렇게 붙여주는 쿼리에 대응하는 방식이다. 해당 옵션에 대해서 파라미터를 처리해주는 거였고, 저 @RequestParam의 내부 파라미터로 required라는 옵션이 있고, 이 default 값이 true인데, 이걸 false로 해주면 저 뒷 부분이 요청에 없어도 에러 뜨지 않는다.

 

이 내부동작은, 아까의 방식에서, 이번에는 controller에 있으니까 그걸 호출해주는 것.

 

 

 

▶ API

 

그러니까 앞선 두개는, 내가 가지고 있는 자료를 렌더링하는 방식이었던 거고 (각각 정적, 동적), 이제는 남의 자료를 가져올 수 있는 방식이다. 하나의 예시는,

 

기존의 것과 다른 점이,

1 ResponseBody라는 @가 생긴 것, 그리고

2 return을 템플릿 엔진으로 하는 게 아니라 그야말로 객체 그 자체(위의 예시의 경우 string)가 반환된다는 점이다.

 

그런데 보통 API에서는 return을, string보다는 다른 걸로 많이 활용한다. 다음을 보면,

이렇게 하면 어떨까?

 

1 public Hello 이런 식으로, Hello라는 우리가 만든 static class를 타입처럼 사용할 수가 있다.

2 우리가 만든 객체를 리턴하게끔 만들면, JSON 객체를 리턴함. 위에서 스트링을 리턴한 것처럼.

3 당연한 거지만, 자바 빈 표준규약에 의해서 변수는 private으로, 함수는 public으로 설정함 - 프로퍼티 방식.

 

이런식으로 JSON을 리턴하는 게 엄청난 파워라고 함. 현재의 API는 JSON을 기본으로 하기 때문에.

그러니까 @ResponseBody가 있다면, 리턴하는 게 string이라면 string converter로, JSON이라면 JsonConverter로.