7. Controller란?

Controller란?

Spring MVC에서 Controller는 클라이언트의 HTTP 요청을 받아 처리하고, 그 결과를 반환하는 역할을 한다.
하나의 Controller에 모든 API를 몰아서 작성하는 것이 아니라, 유사한 성격의 API들을 기준으로 묶어 여러 Controller로 분리하는 것이 일반적이다.

이렇게 구성하면 다음과 같은 장점이 있다.

• 코드 가독성 향상
• 역할 분리로 유지보수 용이
• 기능 단위 확장에 유리

단, 하나의 클래스 내부에서는 메서드명이 중복될 수 없다는 점은 반드시 지켜야 한다.

---

Controller 기본 예제와 문제점

@Controller
public class HelloController {

    @GetMapping("/api/hello")
    @ResponseBody
    public String hello() {
        return "Hello World!";
    }
    
    @GetMapping("/api/hello")
    @ResponseBody
    public String get() {
        return "GET Method 요청";
    }

    @PostMapping("/api/hello")
    @ResponseBody
    public String post() {
        return "POST Method 요청";
    }
}

위 코드에서 확인할 수 있듯이 Path("/api/hello")는 중복될 수 있지만, HTTP Method는 달라야 한다.

Spring은 다음 조합을 기준으로 요청을 구분한다.

• HTTP Method (GET, POST, PUT, DELETE 등)
• URL Path

따라서 같은 Path라도 요청 방식이 다르면 서로 다른 메서드로 처리할 수 있다.

---

@Controller와 @ResponseBody의 관계

@Controller를 사용한 클래스에서 문자열을 반환하면, Spring은 이를 View 이름으로 인식한다.

즉, 반환된 문자열과 동일한 이름의 HTML 파일을 다음 위치에서 찾는다.

• resources/templates/

예를 들어 다음 코드에서

return "Hello World!";

Spring은 Hello World!.html 파일이 존재하는지 확인하고, 해당 View를 렌더링하려고 시도한다.

이는 이전에 학습한 DispatcherServlet의 역할 중

"View 이름 정보를 전달한다"

라는 개념에 해당한다.

하지만 현재 예제에서는 순수한 문자열 데이터 자체를 응답으로 반환하고 싶기 때문에, 반드시 @ResponseBody를 추가해야 한다.

@ResponseBody를 사용하면 반환값을 View로 해석하지 않고, HTTP Response Body에 그대로 담아 클라이언트에 전달한다.

---

공통 Path 중복 문제와 @RequestMapping

API를 작성하다 보면 다음과 같이 공통 Path가 반복되는 경우가 많다.

/api/hello
/api/get
/api/post
/api/put
/api/delete

이를 해결하기 위해 클래스 레벨에서 @RequestMapping을 사용할 수 있다.

@Controller
@RequestMapping("/api")
public class HelloController {

    @GetMapping("/hello")
    @ResponseBody
    public String hello() {
        return "Hello World!";
    }

    @GetMapping("/get")
    @ResponseBody
    public String get() {
        return "GET Method 요청";
    }

    @PostMapping("/post")
    @ResponseBody
    public String post() {
        return "POST Method 요청";
    }

    @PutMapping("/put")
    @ResponseBody
    public String put() {
        return "PUT Method 요청";
    }

    @DeleteMapping("/delete")
    @ResponseBody
    public String delete() {
        return "DELETE Method 요청";
    }
}

동작 방식 정리

• 클래스에 선언된 @RequestMapping("/api")는 공통 URL prefix 역할을 한다.
• 이 Controller로 들어오는 모든 요청은 /api로 시작해야 한다.
• 각 메서드의 Path는 /api 뒤에 이어 붙는 구조가 된다.

즉, 실제 요청 경로는 다음과 같다.

• GET /api/hello
• GET /api/get
• POST /api/post
• PUT /api/put
• DELETE /api/delete

---

추가로 알아두면 좋은 점

• REST API를 주로 작성한다면 @Controller + @ResponseBody 조합 대신
  **@RestController**를 사용하는 것이 일반적이다.
  • @RestController = @Controller + @ResponseBody
• Controller는 요청을 처리하는 역할만 담당하고,
  실제 비즈니스 로직은 Service 계층으로 분리하는 것이 권장된다.

---

정리

Controller는 HTTP 요청을 처리하는 진입점이며,
Path와 HTTP Method를 기준으로 요청을 분기 처리한다.

@RequestMapping을 활용하면 중복되는 URL 구조를 깔끔하게 정리할 수 있고,
@ResponseBody를 통해 View가 아닌 데이터 자체를 응답으로 반환할 수 있다.

Spring MVC에서는 DispatcherServlet이 이러한 과정을 자동으로 처리해 주기 때문에,
개발자는 Controller 작성에만 집중하면 된다.