[스프링부트 및 JPA] - Controller와 Http 4가지 요청 방식

이번 시간엔 Controller에 대해 자세히 다루어보겠습니다.

이전에도 Controller에 대해 설명했지만 이것의 실제 사용에 대한 설명이 미숙한 것 같아 이것이 어떻게 쓰이고 어떻게 데이터를 전달하는지 등을 다루어보려고 합니다.

누군가가 Login요청을 했다고 가정해봅시다.

그러면 원래 스프링부트는 서블릿이라는 것이 만들어져있는데 이 서블릿은 자바로 매핑할 수 있게 만듭니다.

그래서 로그인요청을 하려면 login.java라는 파일을 요청해야 합니다.

회원가입 요청이 들어왔을 때도 join.java를 요청해야할 것입니다.

게시글 쓰기도 요청이 들어올 때 write.java라고 요청해야할 것이니다.

이렇게 요청을 할 때마다 java파일이 호출되기 때문에 이게 너무 번거로운겁니다.

그래서 하나의 java파일에서 모든 요청을 받는 FrontController가 필요해졌습니다.

그러므로 어떻게 할 수 있냐면

login.java
join.java
write.java

이렇게 하나의 세트로 묶어서 하나의 FrontController.java 라고 묶는 것입니다.

그런데 하나의 Controller에 너무 많은 .java파일이 있으면 곤란하겠죠??

막 1개씩 요청이 들어온다 가정했을 때 100개가 들어있는 하나의 컨트롤러를 일일히 꺼내기도 번거로운 것입니다.

그러므로 스프링부트에선 이것을 Domain별로 분기하기 시작합니다.

 

만약 User라는 테이블이 있다면 User와 관련된 로그인, 회원가입 등의 작업을 담당하고

Board라는 테이블이 있다면 Board와 관련된 게시글 쓰기, 게시글 삭제 등의 작업을 담당하게끔 하는 업무를 테마별로 나누어서 분기시키게 됩니다.

이렇게 만들어 놓으면 로그인 요청이나 회원가입 요청이 들어올 때, UserController, BoardController로 나누어서 업무를 수행하게끔 하면 훨씬 더 효율적으로 관리할 수 있습니다.

도메인은 쉽게 말해 범주라고 생각하면 됩니다. (쇼핑몰을 가정한다면 상품, 고객, 지원, 리뷰 이렇게 나눌 수 있겠죠?)

그리고 이 User테이블과 Board 테이블 등의 도메인에 어떤 요청이 들어왔을 때 적절한 요청에 맞게 분배해주는 이 역할은 스프링부트의 DisPatcher가 수행합니다.

정확히 이야기하면 ServletDispatcher 라고 하는데 다른 말로 RequestDispatcher가 수행합니다.

스프링 프레임 워크는 Dispatcher가 이미 만들어져있기 때문에 따로 별도의 설정 없이 Controller를 덮어 씌우기만 하면 자유자재로 개발을 진행할 수 있습니다.

정말 편리하죠?

Service와 Repository등의 어노테이션은 어느 대에 필요한지 알기 위해 조금 있다가 살펴보도록 하겠습니다.

그것보다 훨씬 앞서 이 Controller가 아까 어떤 것을 요청한다고 했었는데 이 요청 파일이 요청 되는 것에 따라 스프링부트가 어떤 작업을 수행하는지 Http의 4가지 동작 방식에 대해 알아보겠습니다.

기본적으로 Http 4가지 동작 방식에는 

GET - 데이터 요청
POST - 데이터 전송
PUT - 데이터 갱신
DELETE - 데이터 삭제

이 구조를 가지고 있습니다.

이것은 클라이언트가 웹 서버에 요청할 때 사용하는데 이를 요청 받은 웹 서버가 DB에 데이터를 SELECT, INSERT, UPDATE, DELETE를 요청해서 응답을 할 수 있습니다.

클라이언트는 웹 브라우저, 즉 사용자를 의미합니다.

예시를 들어보겠습니다.

이런 구조에서 클라이언트가 웹 서버에 Get요청을 보낸다고 해봅시다.

Get은 DB에 SELECT해달라는 것이므로 어떤 데이터를 요청하고 이를 전달받은 DB가 웹 서버와 클라이언트에 차례로 응답하여 원하는 데이터 값을 얻어낼 수 있습니다.

그러므로 DB에 요청할 때 DB에서 쿼리에 대한 결과를 보통 레코드라고 하는데 이것을 응답해줬는데 클라이언트에게 .HTML파일을 돌려줄 수도 있고 어떤 문자열을 돌려줄 수도 있습니다.

그리고 한 가지 주의해야할 것이 있는데 GET요청의 경우 데이터를 요청하는 것이기 때문에 HttpBody가 필요 없습니다.

그런데 POST와 PUT방식은 HttpBody가 필요합니다.

DELETE는 마찬가지로 HttpBody가 필요없습니다.

왜 POST와 PUT은 HttpBody가 필요할까요?

Body는 원래 데이터를 가지고 있습니다.

만약 Post나 Put 요청이 일어나면 이 요청은 HttpBody에 담겨서 이동하게 됩니다.

그런데 Post나 Put은 데이터를 전송하거나 데이터를 갱신하는 것이기 때문에 어떤 데이터를 들고 요청해야 합니다.

예를들어 비밀번호를 바꾸려고 할 때 갱신될 비밀번호를 HttpBody에 담아서 갱신해야 하기 때문에 HttpBody가 필요한 것입니다.

반면에 Get이나 Delete는 데이터를 요청하거나 삭제하는 것이기 때문에 다로 HttpBody가 필요 없는 것입니다.

자 그래서

일단 class를 하나 생성해서 네 가지 요청을 살펴봅시다.

일단 클래스 이름 위에 @RestController 어노테이션을 걸었습니다.

@RestController는 보통 데이터를 리턴받을 때 사용합니다.

@Controller라고 달면 파일을 리턴받을 때 사용할 수 있습니다.

만약 GetMapping 했을 때 return "home.html"; 이렇게 입력하게 되면 파일을 return하는 것이기 때문에 @Controller라고 작성해야하지만 저는 데이터를 응답할 것이기 때문에 @RestController를 달았습니다.

그리고 각각의 메서드를 4가지의 매핑으로 저렇게 작성하고

이렇게 작성합니다.

그리고 작성을 다 하고 서버를 실행하면

localhost:8080/get이라고 입력하면 데이터를 응답하여 아까 return한 get요청이 뜹니다.

하지만 Put과 Post는 조금 다릅니다.

이 친구들을 주소창에 입력하여 검색하면

이런식으로 405에러가 뜹니다.

당연히 delete도 안되는데요. 그래서 프로그램으로 확인을 해보겠습니다.

저는 postman을 써서 확인해보겠습니다.

Post나 Put, Delete모두 Postman을 써서 확인해보니 정상적으로 실행되는 것을 알 수 있습니다.

자 여기서 이제 이해하셨을 것이라 생각합니다.

Get요청은 주소창에 입력하여 데이터를 응답하는 것이기 때문에 개발할 때 어떤 주소를 return받거나 데이터를 받고자할 때 쓸 수 있습니다.

하지만 put, post, delete는 데이터를 응답 받으려고 사용하는 것이 아니고 각각 전송, 갱신, 삭제 등의 목적을 가지고 사용하는 것이기 때문에 주소창에서 확인하는 것은 불가능하다는 것을 알 수 있었습니다.

감사합니다.