잡학다식 개발일지

Spring 이론

웹 개발 방식

스프링 개발의 로드맵

📌 아래는 흔히 스프링 개발에서 사용하는 웹 개발 형식 중 MVC의 내부적 흐름을 표기한 그림이다.

위의 로드맵을 머리속에 그리고 아래의 글을 보면 이해가 쉽다.

전체 개발 단계 요약

1. 기획 및 설계: 목표 정의, 와이어프레임 작성, 기술 스택 결정.
2. 환경 설정: GitLab, AWS, 배포 환경 구성.
3. CI/CD 구축: 자동화된 빌드, 테스트, 배포 설정.
4. 프론트엔드 개발: React로 사용자 인터페이스 개발.
5. 백엔드 개발: NestJS와 RDS MySQL로 서버 및 데이터베이스 구축.
6. 코드 리뷰 및 협업: GitLab 머지 리퀘스트 및 이슈 관리.
7. 테스트 및 최적화: 단위/통합 테스트, 성능 최적화.
8. 출시 및 유지보수: 공식 릴리스 및 지속적 개선.

Spring Framework

📌 Spring Framework는 자바 기반의 애플리케이션 개발을 위한 오픈 소스 프레임워크로, 기업용 애플리케이션 개발에서 널리 사용됩니다. 경량 프레임워크로 시작했지만, 현재는 복잡한 애플리케이션 개발을 단순화하고 생산성을 높이는 강력한 생태계를 제공한다.

Spring Framework 주요 구성 요소

Spring Framework 구성 요소 설명

= 아래는 사전적인 정의로 이해하기 쉽게 아래 접은 글에 설명을 추가해 두었다.

1. Core Container:
   • Core : Spring의 핵심 모듈로, IoC(Inversion of Control)와 DI(Dependency Injection)를 처리.
   • Beans: 객체의 생성, 초기화, 주입, 소멸 등을 관리.
   • Context: ApplicationContext와 같은 고급 IoC 기능 제공.
   • Expression Language: EL을 사용해 객체 속성에 동적으로 접근.
2. AOP:
   • 애플리케이션에서 공통적으로 반복되는 로직(로깅, 보안 등)을 분리.
   • 코드 중복 없이 비즈니스 로직과 공통 로직을 분리 가능.
3. Data Access/Integration:
   • 데이터 접근 및 통합 작업을 단순화.
   • JDBC와 ORM을 위한 템플릿 클래스 제공.
   • 트랜잭션 관리 기능을 제공하여 데이터 무결성을 유지.
4. Web (MVC/Remoting):
   • Spring MVC를 사용해 RESTful API와 동적 웹 애플리케이션을 개발.
   • Servlet과 통합하여 요청 처리.
   • 기존 Struts 프레임워크와 통합 가능.
5. Test:
   • JUnit, TestNG와의 통합으로 단위 테스트와 통합 테스트를 지원.
   • IoC 컨테이너를 사용하여 애플리케이션 컨텍스트를 로드하고 테스트.

IoC와 DI

public class Chef {
    private Ingredient ingredient;

    public Chef() {
        this.ingredient = new Ingredient(); // 요리사가 직접 재료를 생성
    }

    public void cook() {
        System.out.println("Cooking with " + ingredient.getName());
    }
}

public class Ingredient {
    public String getName() {
        return "Tomatoes";
    }
}

public class Chef {
    private Ingredient ingredient;

    // 의존성 주입 (DI)
    public Chef(Ingredient ingredient) {
        this.ingredient = ingredient;
    }

    public void cook() {
        System.out.println("Cooking with " + ingredient.getName());
    }
}

public class Ingredient {
    public String getName() {
        return "Tomatoes";
    }
}

// Spring Configuration
@Configuration
public class AppConfig {
    @Bean
    public Ingredient ingredient() {
        return new Ingredient(); // 의존성 생성
    }

    @Bean
    public Chef chef(Ingredient ingredient) {
        return new Chef(ingredient); // 의존성 주입
    }
}

AOP

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.*;

@Aspect
@Component
public class ExecutionTimeAspect {

    @Around("execution(* com.example.service.*.*(..))")
    public Object measureExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long startTime = System.currentTimeMillis();
        Object result = joinPoint.proceed(); // 메서드 실행
        long endTime = System.currentTimeMillis();
        System.out.println("Execution time of " + joinPoint.getSignature() + ": " + (endTime - startTime) + " ms");
        return result;
    }
}

@Around("execution(* com.example.service.*.*(..))")

@Service
public class ExampleService {
    public void exampleMethod() {
        // 비즈니스 로직
        System.out.println("Executing exampleMethod...");
    }
}

Spring 구조 흐름

• Core Container는 Spring의 기반 기능을 제공.
• AOP는 비즈니스 로직과 공통 로직을 분리.
• Data Access/Integration은 데이터베이스와의 통신 및 메시지 처리를 단순화.
• Web 모듈은 MVC를 지원하여 웹 애플리케이션 개발을 간소화.
• Test는 Spring 애플리케이션의 안정성을 검증.

Spring Framework 특징

스프링 컨테이너(Spring Container)와 스프링 빈(Spring Bean)

1. 스프링 컨테이너(Spring Container)란?

스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트로, 애플리케이션에서 사용하는 객체(빈)를 생성, 관리, 의존성 주입, 생명 주기 관리를 수행하는 도구입니다.

+ 실제로 스프링 컨테이너는 위의 IOC와 DI 개념을 구현하는 도구이다.

스프링 컨테이너의 주요 역할

1. 객체(스프링 빈) 생성:
   • 애플리케이션에서 필요한 객체를 생성합니다.
2. 의존성 주입(DI):
   • 객체 간의 의존성을 설정하고 주입합니다.
3. 객체 생명 주기 관리:
   • 객체의 생성, 초기화, 사용, 소멸 과정을 관리합니다.
4. 빈의 스코프 설정:
   • 객체가 싱글톤인지, 매번 새로운 객체인지 스코프를 정의하고 관리합니다.

2. 스프링 빈(Spring Bean)이란?

스프링 컨테이너가 관리하는 객체를 **스프링 빈(Spring Bean)**이라고 합니다.

스프링 빈의 특징

• 스프링 컨테이너에 의해 생성 및 관리됩니다.
• 기본적으로 **싱글톤(하나의 인스턴스를 공유)**으로 관리됩니다.
• 개발자가 빈을 정의하면, 컨테이너가 이를 관리하고, 의존성을 자동으로 주입합니다.
• 스프링 빈은 보통 어노테이션(@Component, @Service, @Repository, @Controller) 또는 XML 설정으로 등록합니다.

[그래서 스프링 빈은 객체를 어떻게 관리할까?]

@Component
class NotificationService {
    private final MessageService messageService;

    @Autowired
    public NotificationService(MessageService messageService) {
        this.messageService = messageService; // 의존성 주입
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

@Component
class NotificationService {
    private MessageService messageService;

    @Autowired
    public void setMessageService(MessageService messageService) {
        this.messageService = messageService; // 의존성 주입
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

@Component
class ExampleBean implements InitializingBean, DisposableBean {
    // 빈 생성자
    public ExampleBean() {
        System.out.println("1. 빈 생성");
    }

    // 의존성 주입 후 호출
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("2. 빈 초기화");
    }

    // 빈 소멸 전 호출
    @Override
    public void destroy() throws Exception {
        System.out.println("3. 빈 소멸");
    }
}

// 메인 클래스
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Main {
    public static void main(String[] args) {
        // 컨테이너 생성 및 빈 관리 시작
        var context = new AnnotationConfigApplicationContext(AppConfig.class);

        // ExampleBean 사용
        ExampleBean exampleBean = context.getBean(ExampleBean.class);

        // 컨테이너 종료 및 빈 소멸
        context.close();
    }
}

1. 빈 생성
2. 빈 초기화
3. 빈 소멸

3. 스프링 컨테이너와 스프링 빈의 관계

• 스프링 컨테이너는 스프링 빈을 관리하는 도구입니다.
• 개발자는 스프링 컨테이너에 객체(빈)를 등록하고, 컨테이너는 이 빈을 생성하고 관리합니다.
• 스프링 컨테이너는 애플리케이션 실행 시 빈을 생성하고, 의존성을 주입하며, 생명 주기를 관리합니다.

4. 일상적인 예시

1) 스프링 컨테이너와 스프링 빈

• 스프링 컨테이너: **관리인(컨테이너)**이 빵집의 모든 직원과 재료를 관리.
• 스프링 빈: 관리인이 관리하는 **직원(객체)**과 재료(의존성).

비유

• 빵집의 모든 직원은 관리인의 관리하에 빵을 만듭니다.
• 직원들 간의 의존성(예: 반죽 -> 오븐 -> 포장)은 관리인이 연결해줍니다.
• 관리인이 직원의 고용, 교체, 해고(생명 주기)를 관리합니다.

5. 코드 예제

1) 스프링 컨테이너와 빈 등록

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.stereotype.Component;

// 메시지 서비스 인터페이스
interface MessageService {
    void sendMessage(String message);
}

// EmailService 구현체
@Component
class EmailService implements MessageService {
    public void sendMessage(String message) {
        System.out.println("Sending Email: " + message);
    }
}

// NotificationService 클래스
@Component
class NotificationService {
    private final MessageService messageService;

    // 생성자를 통한 의존성 주입
    public NotificationService(MessageService messageService) {
        this.messageService = messageService;
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

// 스프링 설정 클래스
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackages = "com.example")
class AppConfig {
}

// Main 클래스
public class Main {
    public static void main(String[] args) {
        // 스프링 컨테이너 생성
        ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        // 스프링 컨테이너에서 NotificationService 빈 가져오기
        NotificationService notificationService = context.getBean(NotificationService.class);
        notificationService.notify("Hello, Spring!");
    }
}

2) 코드 설명

1. 스프링 컨테이너 생성:
   • ApplicationContext를 통해 스프링 컨테이너를 생성.
   • AppConfig 클래스에서 @ComponentScan으로 스캔한 클래스들을 빈으로 등록.
2. 빈 생성 및 관리:
   • @Component로 등록된 EmailService와 NotificationService는 스프링 컨테이너에 의해 관리됨.
3. 의존성 주입:
   • NotificationService의 생성자에 MessageService 타입의 객체(EmailService)가 자동으로 주입.

6. 정리 표

7. 스프링 컨테이너와 스프링 빈의 관계

1. 컨테이너는 빈을 생성하고 관리:
   • 스프링 컨테이너는 빈을 생성하고, 애플리케이션에서 필요한 의존성을 주입하며, 빈의 생명 주기를 관리합니다.
2. 빈은 컨테이너에 의해 관리되는 객체:
   • 빈은 컨테이너가 생성, 관리하며, 개발자는 컨테이너를 통해 빈을 사용합니다.
   • 빈은 컨테이너가 없으면 독립적으로 존재할 수 없습니다.

결론

• 스프링 컨테이너는 스프링 프레임워크에서 IOC와 DI를 구현하는 핵심 도구로, 애플리케이션의 객체 생성과 의존성 주입을 관리합니다.
• 스프링 빈은 스프링 컨테이너가 관리하는 객체로, 개발자는 이 빈을 사용하여 비즈니스 로직을 구현합니다.
• 스프링 컨테이너와 스프링 빈의 관계는 관리자와 직원의 관계로 비유할 수 있습니다.
  컨테이너가 모든 객체를 생성하고 관리하며, 빈은 각자의 역할에 맞는 작업을 수행합니다.

싱글톤 컨테이너 (Singleton Container)

1. 싱글톤 컨테이너란?

• 싱글톤 컨테이너는 스프링 컨테이너가 애플리케이션 실행 시 한 번 생성된 빈(Bean) 객체를 재사용하도록 관리하는 컨테이너입니다.
• 스프링에서 기본 빈 스코프는 싱글톤이며, 이는 애플리케이션 내에서 동일한 빈 객체가 공유된다는 것을 의미합니다.
• 즉, 동일한 타입의 빈을 여러 번 요청해도 동일한 객체의 참조를 반환합니다.

2. 왜 싱글톤 컨테이너를 사용하는가?

1. 효율적인 메모리 관리:
   • 객체를 한 번만 생성하고 재사용하므로 메모리 낭비를 줄일 수 있습니다.
2. 애플리케이션의 일관성 유지:
   • 여러 컴포넌트에서 같은 빈 객체를 사용하므로 상태 관리가 용이합니다.
3. 객체 생성 비용 절감:
   • 빈을 필요할 때마다 새로 생성하는 대신, 이미 생성된 객체를 재사용하여 성능을 향상시킵니다.

3. 싱글톤 컨테이너의 동작 방식

1. 스프링 컨테이너는 빈 정의를 스캔하여 메모리에 빈 객체를 한 번만 생성합니다.
2. 이후 빈이 필요할 때마다 동일한 객체의 참조를 반환합니다.
3. 기본적으로 모든 빈은 싱글톤 스코프로 관리되지만, 필요에 따라 프로토타입 스코프 등으로 변경할 수 있습니다.

4. 코드 예제

싱글톤 컨테이너 동작

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.stereotype.Component;

@Component
class SingletonBean {
    public SingletonBean() {
        System.out.println("SingletonBean 객체 생성!");
    }

    public void doSomething() {
        System.out.println("SingletonBean 동작 수행!");
    }
}

public class Main {
    public static void main(String[] args) {
        // 스프링 컨테이너 생성
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(Main.class.getPackageName());

        // 동일한 빈을 두 번 조회
        SingletonBean bean1 = context.getBean(SingletonBean.class);
        SingletonBean bean2 = context.getBean(SingletonBean.class);

        // 메서드 호출
        bean1.doSomething();

        // 객체 비교
        System.out.println("bean1 == bean2: " + (bean1 == bean2));

        // 컨테이너 종료
        context.close();
    }
}

실행 결과

SingletonBean 객체 생성!
SingletonBean 동작 수행!
bean1 == bean2: true

5. 코드 설명

1. SingletonBean 정의:
   • @Component를 사용해 스프링 컨테이너에 빈으로 등록.
   • 컨테이너 초기화 시 객체가 한 번 생성됩니다.
2. 컨테이너에서 빈 요청:
   • 두 번 getBean() 메서드를 호출했지만, 동일한 객체를 반환했습니다.
3. 싱글톤 보장:
   • bean1과 bean2는 동일한 객체임을 확인(bean1 == bean2: true).

6. 싱글톤 컨테이너의 한계와 주의점

1. 공유 객체이므로 상태 관리 주의:
   • 싱글톤 빈은 애플리케이션 전역에서 공유되므로, **빈 내부에 상태를 유지(필드에 값 저장 등)**하면 동시성 문제가 발생할 수 있습니다.
   • 상태를 유지하지 않고 **무상태(stateless)**로 설계하는 것이 중요합니다.
2. 멀티스레드 환경에서 동시성 문제:
   • 공유되는 객체이므로 여러 스레드에서 동시에 접근할 경우 동시성 문제가 발생할 수 있습니다.

7. 요약

8. 싱글톤과 프로토타입 비교

9. 결론

• 싱글톤 컨테이너는 애플리케이션 전반에서 하나의 객체를 공유하도록 관리하는 방식으로, 메모리와 성능 면에서 효율적입니다.
• 스프링의 빈은 기본적으로 싱글톤으로 관리되며, 이를 통해 객체 재사용이 보장됩니다.
• 하지만 공유 객체이므로 상태를 유지하지 않도록 설계해야 하며, 동시성 문제를 피하기 위해 빈을 **무상태(stateless)**로 설계하는 것이 중요합니다.
• 필요 시 프로토타입이나 다른 스코프를 사용하여 빈의 생명 주기를 유연하게 관리할 수 있습니다.

컴포넌트 스캔 (Component Scan)

@SpringBootApplication
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;

@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {
}

@ComponentScan(basePackages = {"com.example.service", "com.example.repository"})

@ComponentScan(basePackageClasses = {MyService.class, MyRepository.class})

@ComponentScan(
    basePackages = "com.example",
    includeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = MyCustomAnnotation.class),
    excludeFilters = @ComponentScan.Filter(type = FilterType.REGEX, pattern = "com\\.example\\.exclude\\..*")
)

com.example
 ├── MainApplication.java
 ├── controller
 │    └── MyController.java
 ├── service
 │    └── MyService.java
 └── repository
      └── MyRepository.java

package com.example.controller;

import com.example.service.MyService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @Autowired
    private MyService myService;

    @GetMapping("/")
    public String home() {
        return myService.sayHello();
    }
}

package com.example.service;

import org.springframework.stereotype.Service;

@Service
public class MyService {
    public String sayHello() {
        return "Hello, Component Scan!";
    }
}

package com.example.repository;

import org.springframework.stereotype.Repository;

@Repository
public class MyRepository {
    // Data access logic
}

package com.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MainApplication {
    public static void main(String[] args) {
        SpringApplication.run(MainApplication.class, args);
    }
}

빈 스코프 (Bean Scope)

1. 빈 스코프란?

스프링 빈(Bean) 스코프는 스프링 컨테이너가 빈의 생성과 관리 주기를 결정하는 방식을 의미합니다.
즉, 빈이 언제 생성되고, 몇 번 생성되며, 어떤 범위에서 공유되는지를 정의합니다.

+ 스프링 컨테이너는 프로토타입 빈을 생성하고 의존관계 주입, 초기화까지만 처리한다. 클라이언트에 빈을 반환한 이후에는 스프링 컨테이너는 해당 빈을 관리하지 않는다. 그렇기에 스프링을 떠난 빈은 온전히 클라이언트가 생명주기를 관리해야하며, 그래서 @PreDestory같은 스프링의 어노테이션으로 종료가 안된다. = 이 순간부터 스프링의 객체가 아니다.

2. 스프링이 지원하는 빈 스코프 종류

3. 빈 스코프별 동작 방식

1) Singleton Scope (싱글톤 스코프)

• 특징:
  • 컨테이너 내에 하나의 빈 인스턴스만 생성.
  • 모든 요청에서 동일한 객체를 반환.
• 사용 사례:
  • 공유 데이터나 상태를 가지지 않는 서비스 객체, 비즈니스 로직 처리 클래스.

@Service
public class MySingletonService {
    public String getMessage() {
        return "This is a Singleton Bean";
    }
}

2) Prototype Scope (프로토타입 스코프)

• 특징:
  • 요청할 때마다 새로운 빈 인스턴스를 생성.
  • 빈의 생명 주기를 컨테이너가 관리하지 않음(직접 관리해야 함).
• 사용 사례:
  • 상태가 있는 객체(예: 임시 데이터 저장소).

@Component
@Scope("prototype")
public class MyPrototypeService {
    public String getMessage() {
        return "This is a Prototype Bean";
    }
}

주요 차이점:

• 싱글톤은 동일한 객체를 공유하지만, 프로토타입은 요청마다 새로운 객체를 생성.

3) Request Scope (요청 스코프)

• 특징:
  • HTTP 요청당 하나의 빈 생성.
  • 요청이 종료되면 빈도 소멸.
• 사용 사례:
  • 각 요청마다 고유한 상태를 유지해야 하는 경우.

@Component
@Scope("request")
public class MyRequestBean {
    private String value;

    public String getValue() {
        return value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

주의: 요청 스코프는 웹 애플리케이션 환경(@RestController, @Controller)에서만 사용할 수 있습니다.

4) Session Scope (세션 스코프)

• 특징:
  • HTTP 세션당 하나의 빈 생성.
  • 세션이 종료되면 빈도 소멸.
• 사용 사례:
  • 사용자별 데이터를 유지해야 하는 경우(예: 로그인 상태, 장바구니).

@Component
@Scope("session")
public class MySessionBean {
    private String userData;

    public String getUserData() {
        return userData;
    }

    public void setUserData(String userData) {
        this.userData = userData;
    }
}

5) Application Scope (애플리케이션 스코프)

• 특징:
  • 웹 애플리케이션 컨텍스트 전체에서 하나의 빈 공유.
• 사용 사례:
  • 애플리케이션 전역에서 유지해야 하는 데이터.

@Component
@Scope("application")
public class MyApplicationBean {
    public String getGlobalValue() {
        return "This is an Application Scoped Bean";
    }
}

6) Websocket Scope (웹소켓 스코프)

• 특징:
  • WebSocket 연결당 하나의 빈 생성.
  • 연결 종료 시 빈도 소멸.
• 사용 사례:
  • WebSocket 연결별로 데이터를 유지해야 하는 경우.

@Component
@Scope("websocket")
public class MyWebsocketBean {
    private String connectionId;

    public String getConnectionId() {
        return connectionId;
    }

    public void setConnectionId(String connectionId) {
        this.connectionId = connectionId;
    }
}

4. 빈 스코프 설정 방법

1) 어노테이션 사용

• **@Scope**를 사용하여 빈의 스코프를 지정합니다.

@Component
@Scope("prototype") // 프로토타입 스코프 지정
public class MyPrototypeBean {
    // 빈의 내용
}

2) XML 설정 (스프링 설정 파일 사용)

<bean id="myBean" class="com.example.MyBean" scope="prototype"/>

3) Java Config 사용

@Bean
@Scope("prototype") // 프로토타입 스코프 지정
public MyPrototypeBean myPrototypeBean() {
    return new MyPrototypeBean();
}

5. 정리 표

6. 빈 스코프 선택 기준

1. 싱글톤(Singleton):
   • 공유 데이터를 가지지 않으며, 애플리케이션 전역에서 빈을 공유해야 할 때 사용.
   • 기본값이므로 특별한 이유가 없다면 싱글톤을 사용하는 것이 권장됩니다.
2. 프로토타입(Prototype):
   • 상태를 가지는 객체가 필요하거나 요청 시마다 새로운 인스턴스가 필요할 때.
3. 요청/세션/애플리케이션(Web):
   • 웹 애플리케이션 환경에서 요청별, 세션별, 또는 애플리케이션 전역 데이터를 유지해야 할 때 사용.
4. 웹소켓(WebSocket):
   • WebSocket 기반 통신에서 연결별 데이터를 유지해야 할 때 사용.

7. 결론

• 스프링 빈 스코프는 빈의 생성 주기와 공유 범위를 제어하는 중요한 설정입니다.
• 기본값은 **싱글톤(Singleton)**이며, 대부분의 경우 효율적이고 적합하지만, 특정 상황에서는 프로토타입, 요청, 세션, 애플리케이션 스코프를 활용해야 합니다.
• 스코프를 적절히 설정하면 애플리케이션의 효율성과 유지보수성이 크게 향상됩니다.

Spring Boot

📌 Spring Framework를 기반으로 하여 간편하고 신속하게 애플리케이션을 개발할 수 있도록 도와주는 도구이다.

[1]  Spring Boot의 주요 특징

[2]  Spring Boot의 장점

1. 빠른 시작:
   • Spring Boot는 자동 설정 및 기본적인 템플릿을 제공하여, 애플리케이션을 몇 가지 설정만으로 빠르게 시작할 수 있습니다. @SpringBootApplication 어노테이션을 추가하면, 기본적인 설정이 자동으로 이루어지고, 애플리케이션을 실행할 수 있는 상태가 됩니다.
2. 설정 최소화:
   • Spring Boot는 많은 설정을 자동으로 처리하므로 개발자는 비즈니스 로직에만 집중할 수 있습니다. 예를 들어, 데이터베이스 설정, 서버 설정등 대부분의 설정을 자동으로 처리하여 개발자가 별도로 신경 쓸 필요가 없습니다.
3. 내장 서버:
   • 내장 서버를 제공하여 별도의 외부 웹 서버(Tomcat, Jetty 등이 내장되어 있다.)를 설치할 필요 없이 바로 실행할 수 있습니다. 이는 애플리케이션의 배포를 간소화하고, 실행 파일 하나로 애플리케이션을 배포할 수 있게 만듭니다.
4. 생산성 향상:
   • Spring Boot는 개발자가 빠르게 단독으로 실행할 수 있는 애플리케이션을 작성하고 실행할 수 있도록 돕기 위해 많은 스타터 의존성을 제공합니다. 예를 들어, 웹 애플리케이션을 만들기 위한 spring-boot-starter-web, 데이터베이스 연동을 위한 spring-boot-starter-data-jpa 등이 있습니다.
5. DevTools:
   • Spring Boot는 개발 중에 자동 재시작 및 Hot swapping을 지원하여, 개발자가 코드 수정 후 애플리케이션을 다시 시작하지 않고도 변경 사항을 바로 반영할 수 있도록 돕습니다.

[3]  Spring Boot 애플리케이션 구조

1. 애플리케이션 클래스
   • @SpringBootApplication 어노테이션이 붙은 클래스는 Spring Boot 애플리케이션의 진입점입니다. 이 클래스는 자동으로 필요한 설정을 수행하고 애플리케이션을 실행합니다.

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

1. 자동 설정:
   • Spring Boot는 애플리케이션을 실행할 때, 주어진 환경에 맞춰 자동으로 설정을 적용합니다. 예를 들어, 데이터베이스가 설정되면 자동으로 DataSource와 관련된 설정이 적용됩니다.
2. 프로퍼티 파일:
   • Spring Boot는 application.properties 또는 application.yml 파일을 통해 애플리케이션의 설정을 관리할 수 있습니다. 데이터베이스 연결 정보, 서버 포트, 로깅 수준 등 다양한 설정을 이 파일에서 처리합니다.
3. 내장 서버:
   • Spring Boot는 기본적으로 내장된 Tomcat 서버를 포함하고 있으며, 설정에 따라 다른 내장 서버(Undertow, Jetty 등)를 사용할 수 있습니다.

[4]  Spring Boot 애플리케이션 실행

1. Maven 또는 Gradle을 사용한 빌드 후 실행:
   • 애플리케이션을 빌드하고 실행하려면, mvn spring-boot:run 또는 gradle bootRun 명령을 사용할 수 있습니다.
2. JAR 파일로 실행:
   • Spring Boot 애플리케이션을 JAR 파일로 빌드한 후, java -jar 명령어로 실행할 수 있습니다.

java -jar myapp.jar

[5]  Spring Boot 사용 예시

• 간단한 RESTful 웹 서비스:

@RestController
@RequestMapping("/api")
public class HelloController {
    @GetMapping("/hello")
    public String hello() {
        return "Hello, World!";
    }
}

• 자동 설정 예시: Spring Boot는 데이터베이스 연결을 자동으로 처리할 수 있습니다. 예를 들어, 데이터베이스 설정을 application.properties에서 지정하면, Spring Boot는 이를 자동으로 인식하고 설정을 완료합니다.

spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=secret

Spring MVC

Spring MVC 구조

Spring MVC 실행 흐름 요약

Spring MVC 주요 인터페이스 요약

Spring MVC 주요 컴포넌트와 동작 흐름

HttpMessageConverter

HttpMessageConverter의 역할

• 클라이언트와 서버 간의 HTTP 요청과 응답을 처리할 때 데이터 형식 변환을 담당 합니다. 
• HTTP 요청/응답 본문(body)의 데이터를 객체로 변환하거나, 객체를 특정 형식(JSON, XML 등)으로 변환하여 HTTP 응답 본문에 적합하게 변환하는 역할을 담당합니다.
• 주로 REST API에서 사용되며, JSON이나 XML 데이터를 객체로 역직렬화하거나 객체를 JSON, XML 형식으로 직렬화하는 데 사용됩니다.
• [ View를 응답하는 것이 아닌, Rest API(HTTP API)로 JSON, TEXT, XML 등의 데이터를 응답 Message Body에 직접 입력하는 경우 HttpMessageConverter를 사용합니다. ]

HttpMessageConverter와 다른 컴포넌트의 관계

1. DispatcherServlet:
   • 요청이 들어오면, HandlerMapping과 HandlerAdapter를 통해 적절한 핸들러(Controller)를 실행합니다.
2. HandlerAdapter:
   • 핸들러(Controller)에서 반환된 객체(@ResponseBody 또는 ResponseEntity)를 처리하는 과정에서 HttpMessageConverter를 호출합니다.
   • HttpMessageConverter는 데이터를 변환한 후, View를 렌더링하거나 HTTP 응답 본문에 데이터를 직접 작성합니다.
3. ViewResolver & View:
   • ViewResolver는 논리적 뷰 이름을 실제 뷰로 변환하지만, 만약 JSON이나 XML 데이터로 응답해야 한다면 HttpMessageConverter가 뷰 렌더링 대신 데이터를 직접 변환하여 응답 본문으로 반환합니다.

• 요청시에는 Argument Resolver를 사용합니다.
• 응답시에는 ReturnValueHandler를 사용합니다.

HttpMessageConverter의 동작 흐름

1. 클라이언트가 JSON 데이터를 포함한 HTTP 요청을 보냅니다.
2. DispatcherServlet이 요청을 HandlerAdapter로 전달합니다.
3. HandlerAdapter는 컨트롤러(핸들러)를 호출하여 요청을 처리합니다.
4. 컨트롤러가 객체(예: @ResponseBody 또는 ResponseEntity)를 반환합니다.
5. HandlerAdapter가 반환된 데이터를 처리하기 위해 적절한 **HttpMessageConverter**를 선택합니다.
6. HttpMessageConverter는 데이터를 변환(JSON ↔ 객체)하여 응답 본문에 작성하거나, 요청 본문에서 데이터를 추출합니다.

HttpMessageConverter가 처리하는 경우

• 요청 데이터 변환:
  • JSON, XML, plain text 데이터를 컨트롤러가 처리할 수 있는 Java 객체로 변환.
• 응답 데이터 변환:
  • 컨트롤러에서 반환한 Java 객체를 JSON, XML, plain text 형식으로 변환하여 클라이언트에 전달.

HttpMessageConverter가 없는 경우와 있는 경우

없는 경우:

@RestController
public class MyController {
    @GetMapping("/data")
    public String getData() {
        return "{ \"key\": \"value\" }"; // 직접 JSON 문자열 작성
    }
}

• JSON 데이터를 직접 작성해야 하므로 불편하고 오류 가능성이 높습니다.

있는 경우 (HttpMessageConverter 사용):

@RestController
public class MyController {
    @GetMapping("/data")
    public MyResponse getData() {
        return new MyResponse("value"); // 객체를 반환
    }
}

class MyResponse {
    private String key;

    public MyResponse(String key) {
        this.key = key;
    }

    // Getter/Setter
}

• 컨트롤러는 Java 객체를 반환하며, HttpMessageConverter가 이를 JSON으로 변환하여 클라이언트에 응답합니다.

정리 표

컴포넌트 역할

결론

• HttpMessageConverter는 HandlerAdapter와 View 사이에서 데이터 변환을 담당합니다.
• 요청 데이터(JSON, XML 등)를 Java 객체로 변환하거나, 컨트롤러에서 반환한 객체를 JSON, XML 등으로 변환해 응답 본문으로 작성하는 데 사용됩니다.
• REST API 개발에서 매우 중요한 역할을 하며, Spring MVC의 데이터 처리 흐름을 간단하게 만들어줍니다.

WebMvcConfigurer

• WebMvcConfigurer는 스프링 프레임워크에서 제공하는 인터페이스로, 스프링 MVC의 동작을 사용자 정의할 수 있는 방법을 제공합니다.
• 기본적으로 스프링은 자동 설정(Auto Configuration)을 통해 대부분의 MVC 설정을 처리하지만, 필요한 경우 개발자가 이를 커스터마이징할 수 있도록 WebMvcConfigurer를 제공합니다.

1. WebMvcConfigurer의 역할

WebMvcConfigurer를 구현하여 다음과 같은 스프링 MVC 동작을 커스터마이징할 수 있습니다:

1. 요청 매핑(Custom Request Mapping):
   • 특정 URL 패턴의 요청 처리 방식을 사용자 정의.
2. CORS 설정:
   • 특정 도메인에서의 Cross-Origin 요청을 허용하거나 제한.
3. 정적 리소스 핸들링:
   • 정적 리소스(예: CSS, JS, 이미지) 경로 설정.
4. 뷰 컨트롤러(View Controller) 추가:
   • 컨트롤러 없이 URL에 대해 바로 뷰를 반환하도록 설정.
5. 포맷터(Formatter) 및 변환기(Converter) 등록:
   • 커스텀 데이터 타입 변환 또는 데이터 포맷팅.
6. 인터셉터 등록:
   • 요청 전후 처리에 대한 로직 추가.
7. MessageConverter 등록:
   • 요청/응답 데이터의 변환 규칙 추가 또는 커스터마이징.

2. WebMvcConfigurer를 사용하는 방법

1) 기본적인 구현

스프링에서 WebMvcConfigurer를 구현하는 클래스는 다음과 같습니다:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {
    // 필요한 메서드 오버라이드
}

• @Configuration:
  • 이 클래스가 설정 클래스임을 나타냅니다.
• WebMvcConfigurer:
  • 인터페이스로, 필요한 메서드만 선택적으로 오버라이드할 수 있습니다.

3. WebMvcConfigurer에서 커스터마이징 예제

1) 정적 리소스 경로 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/static/**") // URL 패턴
                .addResourceLocations("classpath:/static/"); // 실제 리소스 경로
    }
}

• 설명:
  • /static/** URL 요청은 classpath:/static/ 경로의 정적 리소스로 매핑됩니다.
  • 예: /static/image.png 요청 → src/main/resources/static/image.png로 응답.

2) CORS 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/api/**") // 특정 URL 패턴
                .allowedOrigins("http://example.com") // 허용할 도메인
                .allowedMethods("GET", "POST"); // 허용할 HTTP 메서드
    }
}

• 설명:
  • /api/** 경로의 요청에 대해 http://example.com 도메인에서의 GET, POST 요청만 허용합니다.

3) 뷰 컨트롤러 설정

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/home") // URL 요청
                .setViewName("home"); // 반환할 뷰 이름
    }
}

• 설명:
  • /home 요청 시 컨트롤러 없이 바로 home.html을 반환합니다.

4) 인터셉터 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new MyInterceptor())
                .addPathPatterns("/api/**") // 인터셉터 적용 경로
                .excludePathPatterns("/api/public/**"); // 제외 경로
    }
}

• 설명:
  • MyInterceptor가 /api/** 요청을 처리하며, /api/public/** 경로는 제외됩니다.

5) 커스텀 MessageConverter 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

import java.util.List;

@Configuration
public class MyWebMvcConfig implements WebMvcConfigurer {

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        converters.add(new MyCustomMessageConverter());
    }
}

• 설명:
  • 사용자 정의 HttpMessageConverter를 등록하여 요청/응답 데이터를 커스터마이징합니다.

4. WebMvcConfigurer의 주요 메서드

5. 요약 표

6. 결론

• WebMvcConfigurer는 스프링 MVC의 동작을 세부적으로 커스터마이징할 수 있는 강력한 도구입니다.
• REST API 개발, CORS 설정, 정적 리소스 처리 등 다양한 요구사항을 처리할 때 사용됩니다.
• 필요한 메서드만 선택적으로 오버라이드하면 되므로 설정이 간단하며, 스프링의 기본 동작과 충돌 없이 동작합니다.

Spring 타입 변형 

TypeConverter

• TypeConverter는 스프링 프레임워크에서 다양한 타입 간의 변환을 지원하는 인터페이스입니다.
  주로 사용자 입력 값(HTTP 요청 파라미터, 쿼리 매개변수 등)을 컨트롤러 메서드의 매개변수에 매핑하거나, 빈의 속성을 설정할 때 사용됩니다.
• 이는 개발자가 **String 타입의 입력값을 Java 객체(예: Date, Enum 등)**로 변환하거나, Java 객체를 다시 String으로 변환할 수 있도록 돕습니다.

1. TypeConverter의 역할

1. 입력 값 변환:
   • HTTP 요청 파라미터나 쿼리 매개변수를 컨트롤러 메서드의 매개변수로 변환.
   • 예: String "123"을 Integer로 변환.
2. 빈 속성 변환:
   • 설정 파일(예: application.properties)의 속성을 빈 속성 값으로 변환.
   • 예: "2025-01-01" → LocalDate.
3. 커스텀 타입 지원:
   • 기본 제공 타입 외에 사용자 정의 타입을 지원하도록 확장 가능.

2. 기본 동작

스프링은 기본적인 타입 변환을 지원합니다. 예를 들어, 아래의 기본 변환은 자동으로 처리됩니다:

• String → int, long, double, boolean.
• String → Date, LocalDate, LocalDateTime.
• String → Enum.

3. TypeConverter의 구현 및 사용

1) 기본 사용 (스프링 자동 변환)

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @GetMapping("/convert")
    public String convert(@RequestParam("id") int id, @RequestParam("active") boolean active) {
        return "Converted ID: " + id + ", Active: " + active;
    }
}

• 입력 요청:

  GET /convert?id=123&active=true
  

• 결과:

  Converted ID: 123, Active: true
  

스프링은 String으로 들어오는 id와 active 파라미터를 각각 int와 boolean으로 자동 변환합니다.

2) 커스텀 타입 변환기 작성

스프링의 기본 변환 외에 사용자 정의 변환기를 등록할 수 있습니다.

1. 사용자 정의 타입

public class CustomType {
    private String value;

    public CustomType(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }

    @Override
    public String toString() {
        return "CustomType{" +
                "value='" + value + '\'' +
                '}';
    }
}

2. TypeConverter 구현

import org.springframework.core.convert.converter.Converter;
import org.springframework.stereotype.Component;

// String -> CustomType 변환기
@Component
public class StringToCustomTypeConverter implements Converter<String, CustomType> {

    @Override
    public CustomType convert(String source) {
        return new CustomType(source);
    }
}

3. 컨트롤러에서 사용

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyController {

    @GetMapping("/custom-convert")
    public String customConvert(@RequestParam("value") CustomType customType) {
        return "Converted Value: " + customType.getValue();
    }
}

입력 요청:

GET /custom-convert?value=test

결과:

Converted Value: test

스프링은 StringToCustomTypeConverter를 사용해 요청 파라미터 "test"를 CustomType 객체로 변환합니다.

4. TypeConverter 등록

스프링에서 커스텀 변환기를 등록하려면 **WebMvcConfigurer**를 사용합니다:

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToCustomTypeConverter());
    }
}

5. TypeConverter와 관련된 컴포넌트

1. ConversionService:
   • 스프링의 타입 변환을 총괄하는 서비스.
   • TypeConverter를 등록하고 관리.
   • 기본 구현: DefaultConversionService.
2. FormatterRegistry:
   • 변환기와 포맷터를 등록하는 레지스트리.
3. Converter:
   • TypeConverter의 구체적인 구현체로, 한 타입을 다른 타입으로 변환하는 로직을 작성.

6. 정리 표

항목 내용

7. 결론

• TypeConverter는 스프링에서 입력 데이터(문자열 등)를 원하는 타입(Java 객체 등)으로 변환하거나, Java 객체를 특정 포맷(String 등)으로 변환하는 데 사용됩니다.
• 기본적으로 제공되는 변환 외에도, 사용자 정의 변환기를 등록해 스프링의 타입 변환 기능을 확장할 수 있습니다.
• REST API나 요청 파라미터의 데이터 처리 과정에서 매우 유용하며, 데이터 타입 변환을 간단하고 일관되게 관리할 수 있도록 도와줍니다.

ConversionService

• **ConversionService**는 스프링 프레임워크에서 제공하는 인터페이스로, 한 타입을 다른 타입으로 변환하는 데 사용됩니다.
• 이는 타입 변환을 중앙에서 관리하고, 통합된 방식으로 변환기를 사용할 수 있도록 도와줍니다.

1. ConversionService의 역할

• 타입 변환의 중심 역할:
  • Converter를 관리하고, 필요한 경우 적절한 변환기를 선택해 타입 변환을 수행합니다.
• 기본 제공 변환:
  • String ↔ Integer, String ↔ Boolean, String ↔ Date, String ↔ Enum 등.
• 커스텀 타입 변환:
  • 사용자 정의 타입 변환기를 등록해 특정 타입 간의 변환도 처리할 수 있습니다.

2. ConversionService의 구현체

• 스프링은 ConversionService 인터페이스를 구현한 기본 클래스들을 제공합니다:
  1. DefaultConversionService:
     • 스프링에서 제공하는 기본 변환 서비스.
     • 대부분의 변환 작업에 대해 기본 구현을 제공하며, 추가 변환기를 등록할 수도 있습니다.
  2. GenericConversionService:
     • 커스텀 변환기 등록을 지원하는 범용 변환 서비스.
  3. FormattingConversionService:
     • DefaultConversionService를 확장하며, 포맷터(Formatter)를 지원.

3. ConversionService 사용 방법

1) 기본 제공 변환

스프링은 DefaultConversionService를 통해 다양한 타입 변환을 기본 제공하며, 이를 직접 사용할 수 있습니다.

import org.springframework.core.convert.support.DefaultConversionService;
import org.springframework.core.convert.ConversionService;

public class Main {
    public static void main(String[] args) {
        // DefaultConversionService 생성
        ConversionService conversionService = new DefaultConversionService();

        // 기본 변환 사용
        int convertedInt = conversionService.convert("123", Integer.class);
        boolean convertedBool = conversionService.convert("true", Boolean.class);

        // 결과 출력
        System.out.println("Converted Integer: " + convertedInt); // 123
        System.out.println("Converted Boolean: " + convertedBool); // true
    }
}

2) 커스텀 변환기 등록

1. 커스텀 변환기 작성

import org.springframework.core.convert.converter.Converter;

// String -> CustomType 변환기
public class StringToCustomTypeConverter implements Converter<String, CustomType> {

    @Override
    public CustomType convert(String source) {
        return new CustomType(source);
    }
}

// CustomType 클래스
public class CustomType {
    private final String value;

    public CustomType(String value) {
        this.value = value;
    }

    public String getValue() {
        return value;
    }
}

2. Custom ConversionService 설정

import org.springframework.core.convert.support.GenericConversionService;

public class Main {
    public static void main(String[] args) {
        // ConversionService 생성
        GenericConversionService conversionService = new GenericConversionService();

        // 커스텀 변환기 등록
        conversionService.addConverter(new StringToCustomTypeConverter());

        // 변환 수행
        CustomType customType = conversionService.convert("test-value", CustomType.class);

        // 결과 출력
        System.out.println("Converted CustomType Value: " + customType.getValue());
    }
}

4. ConversionService와 FormatterRegistry

• **ConversionService**는 변환기(Converter)를 관리하며, 타입 변환을 처리합니다.
• **FormatterRegistry**는 포맷터(Formatter)를 지원하며, ConversionService의 확장된 형태로 볼 수 있습니다.
• WebMvcConfigurer에서 FormatterRegistry를 사용하여 변환기나 포맷터를 등록할 수 있습니다.

변환기 등록

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addConverter(new StringToCustomTypeConverter());
    }
}

5. ConversionService와 Spring MVC의 관계

Spring MVC에서의 ConversionService 동작

• 입력 요청 처리:
  • HTTP 요청 파라미터를 컨트롤러 메서드의 매개변수로 매핑할 때 사용.
  • 예: "123" → Integer.
• 출력 응답 처리:
  • 컨트롤러 메서드의 반환값을 클라이언트로 전송할 데이터 형식으로 변환.
  • 예: Java 객체 → String.

6. 주요 메서드

7. 정리

8. 결론

• **ConversionService**는 스프링에서 타입 변환을 통합적으로 관리하는 강력한 도구입니다.
• 기본 제공 변환기 외에도, 사용자 정의 변환기를 등록해 커스텀 타입 간의 변환을 처리할 수 있습니다.
• HTTP 요청, 응답, 빈 설정 등 다양한 상황에서 일관된 방식으로 타입 변환을 처리하여 개발자의 부담을 줄이고 코드의 유지보수성을 높입니다.

Formatter

• Formatter는 스프링에서 제공하는 인터페이스로, 문자열(String)을 특정 객체로 변환하거나, 객체를 문자열로 변환하는 데 사용됩니다.
• 특히, **지역화(Localization)**를 지원하여 날짜, 숫자 등의 데이터 포맷팅과 같은 작업에 적합합니다.

1. Formatter의 역할

1. 문자열 → 객체 변환:
   • 사용자가 입력한 문자열 데이터를 특정 Java 객체로 변환.
   • 예: "2025-01-01" → LocalDate.
2. 객체 → 문자열 변환:
   • Java 객체를 특정 형식의 문자열로 변환하여 사용자에게 출력.
   • 예: LocalDate.of(2025, 1, 1) → "2025-01-01".
3. 지역화(Localization):
   • 포맷팅 작업 시, Locale을 고려하여 데이터를 변환.

2. Formatter와 Converter의 차이점

3. Formatter와 ConversionService의 관계

• **ConversionService**는 다양한 타입 간의 변환을 관리하는 중심 인터페이스입니다.
• Formatter는 **FormattingConversionService**에 등록되어 동작하며, 주로 사용자 입력값의 포맷팅 작업을 처리합니다.
• 즉, Formatter는 ConversionService의 한 부분으로, 특정 포맷의 데이터를 처리할 때 사용됩니다.

4. Formatter 사용 방법

1) Formatter 구현

import org.springframework.format.Formatter;

import java.text.ParseException;
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class LocalDateFormatter implements Formatter<LocalDate> {

    private static final DateTimeFormatter FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd");

    @Override
    public LocalDate parse(String text, Locale locale) throws ParseException {
        return LocalDate.parse(text, FORMATTER); // 문자열 → LocalDate 변환
    }

    @Override
    public String print(LocalDate object, Locale locale) {
        return object.format(FORMATTER); // LocalDate → 문자열 변환
    }
}

2) Formatter 등록

Formatter를 사용하려면 스프링의 WebMvcConfigurer 또는 FormattingConversionService에 등록해야 합니다.

import org.springframework.context.annotation.Configuration;
import org.springframework.format.FormatterRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(FormatterRegistry registry) {
        registry.addFormatter(new LocalDateFormatter()); // Formatter 등록
    }
}

3) 컨트롤러에서 사용

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.time.LocalDate;

@RestController
public class MyController {

    @GetMapping("/date")
    public String getDate(@RequestParam("date") LocalDate date) {
        return "Parsed Date: " + date;
    }
}

• 요청: /date?date=2025-01-01
• 응답: Parsed Date: 2025-01-01

5. 주요 메서드

6. 정리 표

7. Formatter와 Converter의 활용 예

8. 결론

• Formatter는 문자열과 객체 간의 변환에 특화된 도구로, 지역화(Localization)를 고려한 데이터 포맷팅에 사용됩니다.
• Converter는 더 일반적인 타입 간 변환을 처리하며, 지역화는 지원하지 않습니다.
• ConversionService는 Formatter와 Converter를 통합 관리하며, 다양한 변환 작업을 처리하는 중심 인터페이스 역할을 합니다.
• Formatter는 주로 날짜, 숫자, 통화와 같은 포맷된 데이터를 처리하는 데 적합하며, 사용자 입력값 변환과 출력 포맷팅 작업에서 유용합니다.

Spring 프로그래밍

Spring 웹 애플리케이션 계층 구조 (개발 구조, 만들 것들)

Maven & Gradle

Maven & Gradle 사용 상황 비교

주요 결론

• Maven은 단순성과 표준화를 추구하며, 간단한 프로젝트나 학습용으로 적합합니다.
• Gradle은 유연성과 속도를 중시하며, 대규모 프로젝트나 복잡한 빌드 작업에 유리합니다.

Spring Annotation

주요 어노테이션 분류

Lombok 어노테이션

Spring JPA 어노테이션

기타 어노테이션

장점과 주의점

[참고] 

Lombok

Slf4j와 Lombok의 로깅

@Controller vs @RestController

Spring MVC와 Lombok의 활용

결론

• Lombok은 코드 간소화와 가독성 향상에 특화된 Java 라이브러리로, Spring MVC와 결합 시 생산성을 극대화합니다.
• Slf4j와 Logback은 로깅 관리에서 핵심적인 역할을 하며, Lombok의 @Slf4j로 더욱 간단히 구현 가능합니다.
• @Controller는 뷰 기반 애플리케이션에, @RestController는 데이터 중심 RESTful API 개발에 적합합니다.

[주요 어노테이션 정리]

필터(Filter)

1. 필터란?

**필터(Filter)**는 클라이언트의 요청(request)와 서버의 응답(response) 사이에서 요청 처리 전/후에 특정 작업을 수행할 수 있는 기능을 제공합니다.
필터는 주로 HTTP 요청과 응답을 가로채어 조작하거나, 요청이 컨트롤러에 도달하기 전에 사전 작업을 수행하는 데 사용됩니다.

2. 필터의 주요 사용 사례

1. 인증 및 권한 검사:
   • 요청이 적합한 사용자로부터 왔는지 확인하거나, 요청의 권한을 검증.
2. 로깅 및 모니터링:
   • 요청 및 응답 데이터를 기록하여 애플리케이션의 동작을 추적.
3. 데이터 변환/압축:
   • 요청 데이터 변환 또는 응답 데이터 압축.
4. CORS 처리:
   • Cross-Origin Resource Sharing(CORS) 요청 처리.
5. 보안 작업:
   • CSRF(Cross-Site Request Forgery) 방지 토큰 검증, 헤더 조작 방지 등.

3. 필터의 특징

1. 서블릿 컨테이너에서 동작:
   • 필터는 서블릿 컨테이너(Servlet Container, 예: Tomcat)에서 관리됩니다.
   • 스프링이 제공하는 Filter 인터페이스는 서블릿 표준(javax.servlet.Filter)을 확장한 것입니다.
2. 전역적으로 동작:
   • 컨트롤러에 도달하기 전에 모든 요청/응답에 대해 동작합니다.
3. 체인 방식:
   • 여러 필터가 등록되어 있는 경우, 필터 체인(Filter Chain)을 통해 순서대로 실행됩니다.

4. 필터 구현 방법

1) 기본 필터 구현

javax.servlet.Filter 인터페이스를 구현하여 필터를 작성합니다.

import javax.servlet.*;
import javax.servlet.annotation.WebFilter;
import java.io.IOException;

// 모든 요청에 대해 필터 적용
@WebFilter("/*")
public class LoggingFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // 초기화 작업 (필요 시 구현)
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // 요청 처리 전
        System.out.println("Request received at: " + request.getRemoteAddr());

        // 다음 필터 또는 서블릿 호출
        chain.doFilter(request, response);

        // 응답 처리 후
        System.out.println("Response processed");
    }

    @Override
    public void destroy() {
        // 리소스 해제 작업 (필요 시 구현)
    }
}

• doFilter 메서드:
  • 요청이 컨트롤러로 전달되기 전, 특정 작업을 수행합니다.
  • chain.doFilter(request, response)를 호출하여 다음 필터 또는 서블릿으로 요청을 전달합니다.
  • chain.doFilter 이후 코드는 응답이 생성된 후 실행됩니다.

2) 스프링 부트에서 필터 등록

스프링 부트에서는 @Bean을 사용해 필터를 등록할 수 있습니다.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.servlet.Filter;

@Configuration
public class FilterConfig {

    @Bean
    public Filter loggingFilter() {
        return new LoggingFilter();
    }
}

5. 필터 체인(Filter Chain)

필터는 여러 개 등록될 수 있으며, 등록 순서에 따라 체인 방식으로 동작합니다.

• 필터가 호출될 때, FilterChain을 통해 다음 필터로 요청을 전달합니다.
• 최종적으로 컨트롤러나 서블릿에 도달하며, 응답은 필터 체인을 역순으로 통과합니다.

6. 필터의 실행 순서 지정

스프링 부트에서는 @Order 또는 FilterRegistrationBean을 사용해 필터의 실행 순서를 지정할 수 있습니다.

1) @Order로 순서 지정

import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;

@Component
@Order(1) // 낮은 숫자가 먼저 실행됨
public class FirstFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("First Filter - Before");
        chain.doFilter(request, response);
        System.out.println("First Filter - After");
    }
}

2) FilterRegistrationBean으로 순서 지정

import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class FilterConfig {

    @Bean
    public FilterRegistrationBean<LoggingFilter> loggingFilter() {
        FilterRegistrationBean<LoggingFilter> registrationBean = new FilterRegistrationBean<>();
        registrationBean.setFilter(new LoggingFilter());
        registrationBean.setOrder(2); // 순서 지정 (낮은 숫자가 먼저 실행)
        registrationBean.addUrlPatterns("/*"); // 필터를 적용할 URL 패턴
        return registrationBean;
    }
}

7. 예제: 인증 필터

JWT 인증 필터

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class JwtAuthFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        String authHeader = httpRequest.getHeader("Authorization");

        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            httpResponse.getWriter().write("Unauthorized");
            return;
        }

        String token = authHeader.substring(7); // "Bearer " 이후의 토큰 추출
        if (!validateToken(token)) {
            httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            httpResponse.getWriter().write("Invalid token");
            return;
        }

        chain.doFilter(request, response); // 다음 필터로 요청 전달
    }

    private boolean validateToken(String token) {
        // 토큰 검증 로직 구현
        return "valid-token".equals(token);
    }
}

설정:

@Bean
public FilterRegistrationBean<JwtAuthFilter> jwtAuthFilter() {
    FilterRegistrationBean<JwtAuthFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(new JwtAuthFilter());
    registrationBean.addUrlPatterns("/secure/*"); // 특정 URL 패턴에만 적용
    registrationBean.setOrder(1);
    return registrationBean;
}

8. 정리

9. 결론

필터는 HTTP 요청과 응답을 처리하는 강력한 전처리/후처리 메커니즘으로, 인증, 로깅, 데이터 조작 등 다양한 작업을 수행할 수 있습니다.
스프링 부트에서는 간단한 설정으로 필터를 등록하고, 순서를 지정하여 유연하게 요청/응답 처리를 관리할 수 있습니다.
필터는 전역적으로 동작하기 때문에, 컨트롤러 단위보다 요청 흐름의 초기 단계에서 작업을 수행할 때 적합합니다.

API 예외처리

• API 예외처리는 클라이언트와 서버 간의 상호작용 중 발생할 수 있는 오류를 처리하고, 클라이언트에 일관된 오류 응답을 제공하기 위한 방법입니다.

1. API 예외처리의 목표

1. 일관성:
   • 클라이언트가 API의 오류를 쉽게 이해하고 처리할 수 있도록, 표준화된 형식의 오류 응답 제공.
2. 가독성:
   • 명확한 오류 메시지와 상태 코드 전달로 디버깅과 문제 해결을 간소화.
3. 보안:
   • 민감한 서버 내부 정보를 클라이언트에 노출하지 않음.

2. 기본적인 예외 처리 방식

1) @ExceptionHandler 사용

• 특정 컨트롤러에서 발생한 예외를 처리하기 위한 메서드를 지정합니다.
• 단일 컨트롤러 내에서 예외를 처리한 후
• 계층별로 알맞은 예외를 발생(throw new)시키기만 하면됩니다.

스프링 MVC에서 컨트롤러 단위로 예외를 처리할 수 있습니다.

import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.http.ResponseEntity;

@RestController
public class MyController {

    @GetMapping("/example")
    public String example() {
        if (true) {
            throw new IllegalArgumentException("Invalid input!");
        }
        return "Success";
    }

    // 특정 예외 처리
    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> handleIllegalArgumentException(IllegalArgumentException e) {
        return ResponseEntity.badRequest().body("Error: " + e.getMessage());
    }
}

결과:

• 요청: GET /example
• 응답: 
• { "error": "Error: Invalid input!" }

• 문제점
  1. Controller 코드에 Exception 처리를 위한 책임이 추가된다.(단일 책임 원칙 위반)
  2. 단일 컨트롤러 내의 예외만 처리가 가능하다.(컨트롤러 예외처리 중복코드)
  3. 코드 재사용, 유지보수성 부족

2) @ControllerAdvice 사용

@ControllerAdvice는 애플리케이션 전역에서 예외를 처리할 수 있도록 해줍니다.
컨트롤러마다 예외 처리 로직을 반복하지 않아도 됩니다.

import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> handleIllegalArgumentException(IllegalArgumentException e) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("Error: " + e.getMessage());
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<String> handleGeneralException(Exception e) {
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Unexpected error occurred!");
    }
}

결과:

• 모든 컨트롤러에서 발생하는 예외를 처리할 수 있습니다.
• 예외마다 별도의 처리 로직을 정의할 수 있습니다.

3) ResponseEntityExceptionHandler 상속

스프링의 기본 예외 처리 기능을 확장하여 API 예외 처리를 커스터마이징할 수 있습니다.

import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.context.request.WebRequest;
import org.springframework.web.servlet.mvc.method.annotation.ResponseEntityExceptionHandler;

@ControllerAdvice
public class CustomResponseEntityExceptionHandler extends ResponseEntityExceptionHandler {

    @Override
    protected ResponseEntity<Object> handleExceptionInternal(Exception ex, Object body,
                                                             HttpHeaders headers, HttpStatus status, WebRequest request) {
        return new ResponseEntity<>(new ErrorResponse("INTERNAL_ERROR", ex.getMessage()), status);
    }

    // 사용자 정의 예외 처리
    @ExceptionHandler(CustomException.class)
    public ResponseEntity<Object> handleCustomException(CustomException ex) {
        return new ResponseEntity<>(new ErrorResponse("CUSTOM_ERROR", ex.getMessage()), HttpStatus.BAD_REQUEST);
    }
}

class ErrorResponse {
    private String code;
    private String message;

    public ErrorResponse(String code, String message) {
        this.code = code;
        this.message = message;
    }

    // Getters and setters
}

3. 응답 형식 표준화

JSON 형식의 응답을 사용하여 클라이언트가 오류를 쉽게 이해하도록 일관된 구조를 제공합니다.

표준 오류 응답 예시

{
  "timestamp": "2025-01-01T12:34:56",
  "status": 400,
  "error": "Bad Request",
  "message": "Invalid input",
  "path": "/example"
}

오류 응답 데이터 클래스

import java.time.LocalDateTime;

public class ApiError {
    private LocalDateTime timestamp;
    private int status;
    private String error;
    private String message;
    private String path;

    public ApiError(int status, String error, String message, String path) {
        this.timestamp = LocalDateTime.now();
        this.status = status;
        this.error = error;
        this.message = message;
        this.path = path;
    }

    // Getters and setters
}

ControllerAdvice에서 응답 사용

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<ApiError> handleIllegalArgumentException(IllegalArgumentException e, WebRequest request) {
        ApiError error = new ApiError(
                HttpStatus.BAD_REQUEST.value(),
                "Bad Request",
                e.getMessage(),
                request.getDescription(false)
        );
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(error);
    }
}

4. RestController와 연동

• @RestController와 @ControllerAdvice를 함께 사용하면, REST API에서 발생하는 모든 예외를 처리할 수 있습니다.
• 모든 응답은 JSON 형식으로 변환됩니다.

5. 정리 표

6. 결론

• API 예외 처리는 클라이언트와의 통신에서 중요한 요소로, 오류가 발생했을 때 클라이언트가 이를 쉽게 이해하고 적절히 처리할 수 있도록 돕습니다.
• 스프링에서는 @ControllerAdvice, @ExceptionHandler, ResponseEntityExceptionHandler와 같은 도구를 제공하여 효과적으로 예외를 처리하고, 응답을 일관되게 관리할 수 있습니다.
• 표준화된 JSON 응답 형식을 사용하면 클라이언트와 서버 간의 협업이 더 원활해집니다.

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

의존관계 주입

📌 객체 간의 의존성을 스프링 컨테이너가 자동으로 관리하고 주입해주는 설계 패턴입니다. 객체가 다른 객체를 필요로 할 때, 직접 생성하지 않고 외부에서 주입받아 사용하도록 설계하는 방식입니다.

• @Autowired 는 의존성을 자동으로 주입할 때 사용하는 Annotation 이다.
  • 기본적으로 주입할 대상이 없으면 오류가 발생한다.(required = true)

의존관계 주입의 기본 개념

1. 의존성(Dependency):
   • A 객체가 B 객체를 사용해야 한다면, A는 B에 의존하고 있다고 말합니다.
   • 이때 B 객체를 A 내부에서 직접 생성하지 않고, 외부에서 주입받는 것을 의존관계 주입이라고 합니다.
2. 스프링 DI:
   • 스프링 컨테이너가 객체(빈)를 생성하고 관리하면서 필요한 의존성을 자동으로 주입합니다.
   • 개발자는 직접 의존성을 생성하거나 연결할 필요가 없으며, 컨테이너가 이를 처리합니다.

왜 의존성 주입인가?

@Autowired와 스프링 컨테이너가 있기 때문에, 개발자가 의존 객체를 직접 생성하지 않아도 되고, 컨테이너가 이를 대신 처리합니다. 이 점이 의존성 주입의 핵심입니다.

장점

1. 결합도 감소:
   • MyApp은 MyService의 구체적인 구현체를 몰라도 됩니다. (DIP 원칙 준수)
   • 다른 구현체로 변경할 때 코드 수정이 필요 없습니다.
2. 유연성 증가:
   • 스프링 컨테이너에서 주입받는 객체를 쉽게 교체하거나 확장할 수 있습니다.
3. 테스트 용이성:
   • 테스트 환경에서 Mock 객체를 주입할 수 있습니다.

1. 생성자 주입

• 생성자를 통해 의존성을 주입하는 방법.
• 최초에 한번 생성된 후 값이 수정되지 못한다.[불변, 필수]

public interface MyService {
    void doSomething();
}

// Spring Bean으로 등록
@Service
public class MyServiceImpl implements MyService {
    @Override
    public void doSomething() {
        System.out.println("MyServiceImpl 메서드 호출");
    }
}

// 생성자 주입 방식
@Component
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;

		// 생성자를 통해 의존성 주입, 생략 가능
    @Autowired
    public MyApp(MyService myService) {
        this.myService = myService;
    }

    public void run() {
        myService.doSomething();
    }
    
}

@ComponentScan(basePackages = "com.example.springdependency.test")
public class Main {
    public static void main(String[] args) {

        ApplicationContext context = new AnnotationConfigApplicationContext(Main.class);

        // 등록된 MyApp 빈 가져오기
        MyApp myApp = context.getBean(MyApp.class);

        // 빈 메서드 호출
        myApp.run();
    }
}

-------------------------------------

// 생성자가 두개인 경우 생략이 불가능하다.
@Component
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;
    
    public MyApp(MyService myService, String myRepository) {
        this.myService = myService;
    }

		// 생성자를 통해 의존성 주입
    // @Autowired를 생략하기 위해서는 생성자가 하나여야 한다.
    public MyApp(MyService myService) {
        this.myService = myService;
    }

    public void run() {
        service.doSomething();
    }
    
}

• 생성자가 하나인 경우 @Autowired 생략이 가능하다.
• 둘중 어떤 생성자를 사용해야 하는지 Spring은 알지 못한다.

2. Setter 주입

• Setter 메서드를 통해 의존성을 주입하는 방법.

@Component
public class MyApp {

    private MyService myService;

    // Setter 주입
    @Autowired
    public void setMyService(MyService myService) {
        this.myService = myService;
    }
    
    public void run() {
        myService.doSomething();
    }

}

선택하거나, 변경 가능한 의존관계에 사용한다.(생성자 주입은 필수 값)

// MyService가 Spring Bean으로 등록되지 않은 경우에도 주입이 가능하다.
@Autowired(required = false)
public void setMyService(MyService myService) {
    this.myService = myService;
}

// 실행 도중 인스턴스를 바꾸고자 하는 경우
// setMyService(); 메서드를 외부에서 호출하면 된다.(이런 경우는 거의 없음)

3. 필드 주입

• 필드에 직접적으로 주입하는 방법 (가장 추천되지 않음).

@Component
public class MyApp {

    @Autowired
    private MyService myService;  // 필드에 직접 주입

    public void run() {
        myService.doSomething();
    }
    
}

• 코드는 간결하지만 Spring이 없으면 사용할 수 없다.
  • 사용하지 않아야 한다.

// Spring을 사용하지 않는 경우 실행이 불가능하다.
public class MainV2 {
    public static void main(String[] args) {
        MyApp myApp = new MyApp();
        myApp.run();
    }
}

• 외부에서 myService 값을 설정하거나 변경할 방법이 없다.
  • 결국 setter를 만들어야 한다.
• 순수 Java 코드로 사용할 수 없다. = 테스트 코드 작성이 힘들다.
• Application의 실행과 관계 없는 @SpringBootTest 테스트 코드나 Spring에서만 사용하는 @Configuration 같은 곳에서 주입할 때 주로 사용한다.

4. 일반 메서드 주입

• 생성자, setter 주입으로 대체가 가능하기 때문에 사용하지 않는다.

@Component
public class MyApp {

    private MyService myService;

    // 일반 메서드 주입
    @Autowired
    public void init(MyService myService) {
        this.myService = myService;
    }
    
    public void run() {
        myService.doSomething();
    }

}

생성자 주입

📌 과거 setter, 필드 주입도 사용했지만 현재는 DI를 가지고 있는 대부분의 Framework가 생성자 주입 방식을 권장한다.

생성자 주입을 선택하는 이유

• 불변(immutable)
  • 어떤 요리(Web Application)를 만들지 정해졌다면 이미 재료(Bean)와 의존 관계가 결정된다.
  • 객체를 생성할 때 최초 한번만 호출된다.(불변)
  • setter 주입을 사용하면 접근제어자가 public 으로 설정되어 누구나 수정할 수 있게된다.
• 실수 방지
  • 순수 Java 코드로 사용할 때(주로 테스트 코드) 생성자의 필드를 필수로 입력하도록 만들어준다.(NPE 방지)
  • 컴파일 시점에 오류를 발생 시킨다. 즉, 실행 전에 오류를 알 수 있다.

public class MyApp {
    private MyService myService;

    public MyApp() {
        this.myService = new MyService(); // 직접 생성
    }

    public void run() {
        myService.doSomething();
    }
}

---------------------------------------

@Component // 해당 어노테이션이 MyService 객체를 bean으로 만들어준다. 즉 스프링이 객체 MyService를 저장한다.
public class MyApp {
    private final MyService myService;

    @Autowired
    public MyApp(MyService myService) {
        this.myService = myService; // 외부에서 주입 (직접 선언이 아니라 스프링에 저장된 객체 사용)
    }

    public void run() {
        myService.doSomething();
    }
}

• 위 코드 참고
• @Autowired: 스프링 컨테이너가 MyService 타입의 빈을 찾아서 자동으로 주입합니다.
• MyApp은 MyService를 직접 생성하지 않습니다. 대신, 스프링 컨테이너가 제공한 인스턴스를 사용합니다.

Spring Framework에 의존하지 않아도 객체 지향 특성을 가장 잘 사용하는 방법이다.

@RequiredArgsConstructor

📌 실제 Web Application을 개발하면 대부분이 불변 객체이고 생성자 주입 방식을 선택하게 된다. 이런 반복되는 코드를 편안하게 작성하기 위해 Lombok에서 제공하는 Annotation 이다.

@RequiredArgsConstructor

• final 필드를 모아서 생성자를 자동으로 만들어 주는 역할
• Annotation Processor 가 동작하며 컴파일 시점에 자동으로 생성자 코드를 만들어준다.
• 사용 방법

@Component
@RequiredArgsConstructor
public class MyApp {
		// 필드에 final 키워드 필수! 무조건 값이 있도록 만들어준다.(필수)
    private final MyService myService;
    
    // Annotation Processor가 만들어 주는 코드
    // public MyApp(MyService myService) {
    //     this.myService = myService;
    // }

    public void run() {
        myService.doSomething();
    }
    
}

• 만약 생성자가 필요한 경우가 생긴다면, 생성자 주입 방식을 직접 선언하면 된다.

@ComponentScan

📌 Spring이 특정 패키지 내에서 @Component, @Service, @Repository, @Controller 같은 Annotation이 붙은 클래스를 자동으로 검색하고, 이를 Bean으로 등록하는 기능이다. 개발자가 Bean을 직접 등록하지 않고도 Spring이 자동으로 관리할 객체들을 찾는다.

ComponentScan의 역할

• Chef가 요리할 재료를 자동으로 식료품 저장고에서 찾아오는 과정, Chef는 스스로 필요한 재료를 찾아 요리에 사용한다.

• 요리사(개발자)가 직접 재료(Bean)를 찾아서 가져올 필요가 없다.

@ComponentScan

1. 특정 패키지 내에 @Component Annotation이 붙은 클래스를 자동으로 찾아서 Spring Bean으로 등록한다.
   • Annotation을 이용해 Bean을 등록할 수 있어 코드가 간결해지고 유지보수가 쉬워진다.
2. 스캐닝 범위는 주로 애플리케이션의 루트(최상위) 패키지에서 시작된다.
3. @SpringBootApplication
   • 스프링 부트 애플리케이션의 시작점을 정의하기 위해 사용하는 애너테이션입니다. 이 애너테이션은 여러 기능을 결합한 복합 애너테이션으로, 스프링 부트 애플리케이션을 간단히 설정하고 실행할 수 있도록 돕습니다.
   • SpringBoot로 프로젝트를 생성하면 main() 메서드가 있는 클래스 상단에 @SpringBootApplication Annotation 이 존재한다.

@ComponentScan의 동작 순서

1. 스프링 컨테이너가 빈 등록

• Spring Application이 실행되면 @ComponentScan이 지정된 패키지를 탐색한다.
• @ComponentScan은 @Component, @Service, @Repository, @Controller 등의 애너테이션이 붙은 클래스를 탐색합니다.
• 해당 클래스들을 스프링 빈으로 등록합니다.
• 구현 클래스뿐만 아니라, 인터페이스와 그 구현체도 함께 빈으로 등록됩니다.

2. 의존성 정의 (인터페이스 기반 설계)

• 일반적으로 **인터페이스(추상화)**를 의존성으로 정의합니다.
  구현체는 스프링이 자동으로 선택하고 주입합니다.

3. 구현체 자동 연결

• 스프링은 등록된 빈 중에서 의존성으로 선언된 인터페이스에 맞는 구현체를 자동으로 찾아 주입합니다.
• 이 과정은 타입 매칭을 통해 이루어집니다.

@Configuration, @Bean

📌 Spring Bean을 등록하는 방법에는 수동, 자동 두가지가 존재한다.

Spring Bean 등록 방법

• Spring Bean은 Bean의 이름으로 등록된다.
  • 1. 자동 Bean 등록(@ComponentScan, @Component)
    • @Component 이 있는 클래스의 앞글자만 소문자로 변경하여 Bean 이름으로 등록한다.

// myService 라는 이름의 Spring Bean
@Component
public class MyService {

    public void doSomething() {
        System.out.println("Spring Bean 으로 동작");
    }
    
}

• @ComponentScan 을 통해 @Component로 설정된 클래스를 찾는다.

• 2. 수동 Bean 등록(@Configuration, @Bean)
  • @Configuration 이 있는 클래스를 Bean으로 등록하고 해당 클래스를 파싱해서 @Bean 이 있는 메서드를 찾아 Bean을 생성한다. 이때 해당 메서드의 이름으로 Bean의 이름이 설정된다.

// 인터페이스
public interface TestService {
    void doSomething();
}

// 인터페이스 구현체
public class TestServiceImpl implements TestService {
    @Override
    public void doSomething() {
        System.out.println("Test Service 메서드 호출");
    }
}

// 수동으로 빈 등록
@Configuration
public class AppConfig {
    
    // TestService 타입의 Spring Bean 등록
    @Bean
    public TestService testService() {
        // TestServiceImpl을 Bean으로 등록
        return new TestServiceImpl();
    }
    
}

// Spring Bean으로 등록이 되었는지 확인
public class MainApp {
    public static void main(String[] args) {
        // Spring ApplicationContext 생성 및 설정 클래스(AppConfig) 등록
        ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);

        // 등록된 TestService 빈 가져오기
        TestService service = context.getBean(TestService.class);

        // 빈 메서드 호출
        service.doSomething();
    }
}

Bean 충돌

📌 Bean 등록 방법에는 수동, 자동 두가지가 존재하고 Bean은 각각의 이름으로 생성된다. 이때 이름이 같은 Bean이 설정되고자 한다면 충돌이 발생한다.

같은 이름의 Bean 등록

• 자동 Bean 등록 VS 자동 Bean 등록

public interface ConflictService {
    void test();
}

// Bean의 이름을 service로 설정
@Component("service")
public class ConflictServiceV1 implements ConflictService {
    @Override
    public void test() {
        System.out.println("Conflict V1");
    }
}

// Bean의 이름을 service로 설정
@Component("service")
public class ConflictServiceV2 implements ConflictService {
    @Override
    public void test() {
        System.out.println("Conflict V2");
    }
}

// componentScan의 범위를 conflict 패키지 하위로 설정
@ComponentScan(basePackages = "com.example.springconcept.conflict")
public class ConflictApp {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(ConflictApp.class);

        // Service 빈을 가져와서 실행
        ConflictService service = context.getBean(ConflictService.class);

        service.test();
    }
}

• ConflictingBeanDefinitionException 발생

수동 Bean 등록 VS 자동 Bean 등록

// conflictService 이름으로 Bean 생성
@Component
public class ConflictService implements MyService {
    @Override
    public void doSomething() {
        System.out.println("ConflictService 메서드 호출");
    }
}

public class ConflictServiceV2 implements MyService {
    @Override
    public void doSomething() {
        System.out.println("ConflictServiceV2 메서드 호출");
    }
}

// 수동으로 Bean 등록
@Configuration
public class ConflictAppConfig {
		
		// conflictService 이름으로 Bean 생성
    @Bean(name = "conflictService")
    MyService myService() {
        return new ConflictServiceV2();
    }

}

@ComponentScan(basePackages = "com.example.springconcept.conflict2")
public class ConflictApp2 {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(ConflictApp2.class);

        // Service 빈을 가져와서 실행
        MyService service = context.getBean(MyService.class);

        service.doSomething();
    }
}

• 수동 Bean 등록이 자동 Bean 등록을 오버라이딩해서 우선권을 가진다.
• 의도한 결과라면 다행이지만, 아닌 경우(실수)가 대부분이다. → 버그 발생
• Spring Boot에서는 수동과 자동 Bean등록의 충돌이 발생하면 오류가 발생한다.

더보기

 

설정 변경(application.properties)

// 수동, 자동 Bean을 동시에 등록할 때 이름이 같으면 수동 Bean이 오버라이딩
spring.main.allow-bean-definition-overriding=true 

// 기본값
spring.main.allow-bean-definition-overriding=false

@Qualifier, @Primary

📌 같은 타입의 Bean이 중복된 경우 해결하기 위해 사용하는 Annotation

• 같은 타입의 Bean 충돌 해결 방법
  1. @Autowired + 필드명 사용
     • @Autowired 는 타입으로 먼저 주입을 시도하고 같은 타입의 Bean이 여러개라면 필드 이름 혹은 파라미터 이름으로 매칭한다.

public interface MyService { ... }

@Component
public class MyServiceImplV1 implements MyService { ... }

@Component
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

	// 필드명을 Bean 이름으로 설정
	@Autowired
	private MyService myServiceImplV2;
	...
}

1. @Qualifier 사용
   • Bean 등록 시 추가 구분자를 붙여 준다.
   • 생성자 주입, setter 주입 사용 가능

@Component
@Qualifier("firstService")
public class MyServiceImplV1 implements MyService { ... }

@Component
@Qualifier("secondService")
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

		private MyService myService;

		// 생성자 주입에 구분자 추가
		@Autowired
		public ConflictApp(@Qualifier("firstService") MyService myService) {
				this.myService = myService;
		}
	
		// setter 주입에 구분자 추가
		@Autowired
		public void setMyService(@Qualifier("firstService") MyService myService) {
				this.myService = myService;
		}
	...
}

1. @Primary 사용
   • @Primary로 지정된 Bean이 우선 순위를 가진다.

@Component
public class MyServiceImplV1 implements MyService { ... }

@Component
@Primary
public class MyServiceImplV2 implements MyService { ... }

@Component
public class ConflictApp {

		private MyService myService;

		@Autowired
		public ConflictApp(MyService myService) {
				this.myService = myService;
		}
	...
}

• 실제 적용 사례
  • Database가 (메인 MySQL, 보조 Oracle) 두개 존재하는 경우
    • 기본적으로 MySQL을 사용할 때 @Primary를 사용하면 된다.
    • 필요할 때 @Qualifier로 Oracle을 사용하도록 만들 수 있다.
    • 동시에 사용되는 경우 @Qualifier 의 우선순위가 높다.

수동 VS 자동

📌 Annotation 기반의 Spring에서는 자동 Bean 등록과 의존관계 주입을 사용하는 경우를 주로 사용한다. @Component 뿐만 아니라 @Controller, @Service, @Repository 등 자동으로 쉽게 등록할 수 있는 Annotation들을 지원하고 Spring Boot는 ComponentScan 방식을 기본으로 사용한다.

• 자동 Bean 등록을 사용하는 이유
  1. 다양한 Annotation으로 편리하게 등록할 수 있다.
  2. Spring Boot는 ComponentScan 방식을 기본으로 사용한다.
  3. 간단하지만 OCP, DIP를 준수하며 개발할 수 있다.
• 수동 Bean 등록을 사용하는 경우
  1. 외부 라이브러리나 객체를 Spring Bean으로 등록할 때
     • 외부 라이브러리에서 제공하는 클래스는 자동 등록이 불가능하다.
  2. 데이터베이스 연결과 같이 비지니스 로직을 지원하는 기술들에 사용한다.
     • 비지니스 로직보다 그 수가 아주 적지만 Application에 광범위하게 적용된다.
     • 설정 정보에 명시되어 있어서 유지보수성이 증가한다.
  3. 같은 타입의 Bean 여러개 중 하나를 명시적으로 선택해야 할 때

꼭 필요한 경우가 아니라면 자동 Bean 등록을 사용하면 된다.

Spring Container

📌 Spring으로 구성된 애플리케이션에서 객체(Bean)를 생성, 관리, 소멸하는 역할을 담당한다. 애플리케이션 시작 시, 설정 파일이나 Annotation을 읽어 Bean을 생성하고 주입하는 모든 과정을 컨트롤한다. 심지어는 의존성마저 주입한다.

• 총괄주방장 = shef 라고 보면 편하다.

• Spring Container를 사용하면 인터페이스에만 의존하는 설계가 가능해진다.
  • OCP, DIP 준수

Spring Container의 종류

• BeanFactory
  • Spring Container의 최상위 인터페이스
  • Spring Bean을 관리하고 조회한다.
• ApplicationContext
  • BeanFactory의 확장된 형태(implements) -> 진화된 버전
  • Application 개발에 필요한 다양한 기능을 추가적으로 제공한다.
    • 국제화, 환경변수 분리, 이벤트, 리소스 조회

Spring Bean

📌 Spring 컨테이너가 관리하는 객체를 의미한다. 자바 객체 자체는 특별하지 않지만, Spring이 이 객체를 관리하는 순간부터 Bean이 된다. Spring은 Bean을 생성, 초기화, 의존성 주입 등을 통해 관리한다.

• 모든 객체가 Bean인게 아니라 spring container가 관리하는 객체를 bean이라 하는 것
• Bean은 new 키워드 대신 사용하는 것이다.
• Spring Container가 제어한다.

Spring Bean의 역할

• Chef인 Spring Container가 요리할 음식에 사용될 재료(Bean)
  • 요리(Application)의 핵심을 이루는 재료(Bean)

• Spring Bean의 특징
  1. Spring 컨테이너에 의해 생성되고 관리된다.
  2. 기본적으로 Singleton( 애플리케이션 전역에서 단 하나의 인스턴스만 생성하도록 보장하는 디자인 패턴 )으로 설정된다.
  3. 의존성 주입(DI)을 통해 다른 객체들과 의존 관계를 맺을 수 있다.
  4. 생성, 초기화, 사용, 소멸의 생명주기를 가진다.

Bean 등록 방법

• XML, Java Annotation, Java 설정파일 등을 통해 Bean으로 등록할 수 있다.
  • XML

<beans>
    <!-- myBean이라는 이름의 Bean 정의 -->
    <bean id="myBean" class="com.example.MyBean" />
</beans>

--------------------------------------------------------------------

public class MyApp {
    public static void main(String[] args) {
        // Spring 컨테이너에서 Bean을 가져옴
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        MyService myService = context.getBean("myService", MyService.class);
        myService.doSomething();
    }
}

• Annotation
  • @ComponentScan
  • 개발자가 일일이 빈(Bean)을 설정하지 않아도, 지정한 패키지에서 필요한 클래스들을 자동으로 찾아서 애플리케이션 컨텍스트에 빈(Bean) 등록해 줍니다.

// 이 클래스를 Bean으로 등록
// @Controller, @Service, @Repository
@Component
public class MyService {

    public void doSomething() {
        System.out.println("Spring Bean 으로 동작");
    }
    
}

------------------------------------

@Component
public class MyApp {

    private final MyService myService;

    @Autowired // 의존성 자동 주입
    public MyApp(MyService myService) {
        this.myService = myService;
    }

    public void run() {
        myService.doSomething();
    }
}

---------------------------------------------

// com.example 패키지를 스캔하여 Bean 등록
@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {

    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
        MyApp app = context.getBean(MyApp.class);
        app.run();
    }
    
}

Java 설정파일

@Configuration
public class AppConfig {

    @Bean
    public MyService myService() {
        return new MyService();
    }
}

------------------------------------

public class MyApp {
    public static void main(String[] args) {
        // Spring 컨테이너에서 Bean을 가져옴
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
        MyService myService = context.getBean(MyService.class);
        myService.doSomething();
    }
}

IOC(제어의 역전, Inversion Of Control)

📌 객체의 생성과 관리 권한을 개발자가 아닌 Spring 컨테이너가 담당하는 것을 말한다. 기본적으로 개발자가 객체를 직접 생성하고 관리했지만, Spring에서는 컨테이너가 객체 생성, 주입, 소멸을 관리한다.

• 요리사(개발자)는 필요한 재료를 직접 준비하지 않고, Chef가 알아서 필요한 재료(Bean)을 관리하고 요리사에게 가져다준다.

IoC 개념

1. 객체의 생성 및 생명주기 관리를 개발자가 직접 하는 것이 아니라 컨테이너가 담당한다.
2. 객체 간의 결합도를 낮춰 유연한 코드가 된다.

DI(의존성 주입, Dependency Injection)

📌 Spring이 객체 간의 의존성을 자동으로 주입해주는 것을 의미한다. 한 객체가 다른 객체를 사용할 때, 해당 객체를 직접 생성하지 않고 Spring이 주입해주는 방식이다. IOC를 구현하는 방식 중 하나이다.

• 셰프가 요리를 만들 때 필요한 재료(Bean)를 자동으로 요리사에게 가져다주는 과정
• 요리사(개발자)는 재료를 찾을 필요 없이, Chef가 알아서 제공해준다.

의존성 = 추상화가 아닌 이유

의존성이란, 한 객체가 다른 객체를 사용하거나 그 객체의 기능에 의존하는 관계를 말합니다. 그리고 추상화는 의존성을 설계하는 중요한 방식 중 하나입니다. 하지만 의존성이 항상 추상화와 동일한 개념은 아닙니다. 의존성과 추상화의 관계를 설명하겠습니다.

1. 의존성은 설계의 결과, 추상화는 설계의 방법:
   • 의존성은 클래스 간의 관계를 나타냅니다.
   • 추상화는 의존성을 관리하거나 줄이기 위한 설계 기법입니다.
2. 구체적인 의존성도 존재:
   • 의존성이 항상 추상화된 타입에만 연결되지 않습니다.
   • 구체 클래스에 대한 의존성도 의존성의 한 형태입니다.

IOC, DI 주입 개발자, SPRING 비교 

// Service 인터페이스
public interface MyService {
    void doSomething();
}

// Repository 인터페이스
public interface MyRepository {
    void queryDatabase();
}

// Service 구현체
public class MyServiceImpl implements MyService {
    private MyRepository myRepository;

    // 의존성 주입
    public MyServiceImpl(MyRepository myRepository) {
        this.myRepository = myRepository;
    }

    @Override
    public void doSomething() {
        System.out.println("서비스 작업 실행");
        myRepository.queryDatabase();
    }
}

// Repository 구현체
public class MyRepositoryImpl implements MyRepository {
    @Override
    public void queryDatabase() {
        System.out.println("데이터베이스 쿼리 실행");
    }
}

public class MyApp {
    public static void main(String[] args) {
        MyRepository repo = new MyRepositoryImpl();

				// MyRepository repo2 = new MyRepositoryImplV2();

        MyService myService = new MyServiceImpl(repo);
        
				// MyService myService2 = new MyServiceImpl(repo2);

        myService.doSomething();
    }
}

// 새로운 Repository 구현체
public class MyRepositoryImplV2 implements MyRepository {
    @Override
    public void queryDatabase() {
        System.out.println("데이터베이스 쿼리 실행 V2");
    }
}


---------------------------------


// Service 구현체
@Service
public class MyIocService implements MyService {
    
    private final MyRepository myRepository;

    // 생성자 주입(DI 적용)
	@Autowired: 스프링이 자동으로 MyRepository 타입의 빈(Bean)을 찾아 생성자에 주입하도록 지시합니다.
    public MyIocService(MyRepository myRepository) {
        this.myRepository = myRepository;
    }

    @Override
    public void doSomething() {
        System.out.println("IOC 서비스 작업 실행");
        myRepository.queryDatabase();
    }
}

// Repository 구현체
@Repository
public class MyIocRepository implements MyRepository {

    @Override
    public void queryDatabase() {
        // 데이터베이스와 상호작용
        System.out.println("IOC 데이터베이스 쿼리 실행");
    }
}

// Spring Container 관리(IoC 적용)
@ComponentScan(basePackages = "com.example") 
: @ComponentScan으로 지정된 com.example 패키지를 스캔하여 빈으로 등록할 클래스들을 검색합니다.
public class MyIocApp {

    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(MyIocApp.class);

        // Service 빈을 가져와서 실행
        MyService service = context.getBean(MyService.class);
        service.doSomething();
    }
}

// 새로운 Repository 구현체
@Repository
public class MyIocRepositoryV2 implements MyRepository {

    @Override
    public void queryDatabase() {
        // 데이터베이스와 상호작용
        System.out.println("IOC 데이터베이스 쿼리 실행 V2");
    }
}

• 구현 코드가 변경되어도 클라이언트의 코드에는 영향이 없다.
• 다른 구현체를 구현하여 Bean으로 등록하면 자유롭게 변경이 가능하다.
  • 위 예시 코드는 @Repository 로 등록된 빈이 중복되어 충돌이 발생한다.
• 의존성 주입(DI), 제어의 역전(IOC)을 통해 객체 간의 결합도를 낮추고 유연한 설계가 가능해진다.

IOC/DI

1. IoC는 객체의 제어권을 개발자가 아닌 Spring 컨테이너에게 넘기는 개념으로, Spring이 객체 생성과 관리를 담당한다.
2. DI는 Spring이 객체 간의 의존성을 자동으로 주입해주는 기법이다.
3. 의존관계 주입은 객체 간의 결합도를 낮추고 코드의 유연성과 테스트 가능성을 높여준다.

Singleton Pattern

📌 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴이다.

더보기

public class MainApp {
    public static void main(String[] args) {
       // 첫 번째 싱글톤 인스턴스 요청, 구현클래스.getInstance();
        Singleton instance1 = SingletonImpl.getInstance();
        instance1.showMessage(); // 인스턴스 주소값 출력

        // 두 번째 싱글톤 인스턴스 요청, 구현클래스.getInstance();
        Singleton instance2 = SingletonImpl.getInstance();
        instance2.showMessage(); // 인스턴스 주소값 출력
        
        // 다른 구현체로 바꾸려면 DIP, OCP 위반
        Singleton instance3 = SingletonImplV2.getInstance();
        instance3.showMessage();
    }
}

• 위처럼 인스턴스가 클래스마다 1개씩만 배치된다.
• 다만 보면 알겠지만, 클래스의 개수가 많아지는 것 같은 느낌이 들 것이다.

싱글톤 패턴의 문제점

• 싱글톤 패턴을 구현하기 위한 코드의 양이 많다.
• 구현 클래스에 의존해야 한다.(DIP, OCP 위반)
• 유연성이 떨어져서 안티패턴으로 불리기도 한다.

Spring의 싱글톤 컨테이너

• Spring은 Web Application을 만들 때 주로 사용된다.

• Spring Container는 싱글톤 패턴의 문제점들을 해결하면서 객체를 싱글톤으로 관리한다.
• Spring Bean은 싱글톤으로 관리되는 객체이다.
• Spring이 Bean을 등록하는 방법은 기본적으로 싱글톤 이다. 하지만, 요청할 때 마다 새로운 객체를 생성해서 반환하는 기능도 제공한다.

Spring Bean이 싱글톤을 사용하는 이유

Singleton Pattern의 주의

📌 객체의 인스턴스를 하나만 생성하여 공유하는 싱글톤 패턴의 객체는 상태를 유지(stateful)하면 안된다.

• 지역 변수라면 변수여도 된다. 하지만 요청마다 값이 변경되거나 외부에서 변경 가능한 데이터가 싱글톤 객체에 저장되면 문제가 생길 수 있다.
• 즉 공유 객체( 여러 사용자나 스레드가 동시에 접근하여 값을 읽거나 수정할 수 있는 데이터 )는 안된다.

상태 유지(stateful)의 문제점

• 데이터의 불일치나 동시성 문제가 발생할 수 있다.
• 코드예시

public class StatefulSingleton {
    private static StatefulSingleton instance;
    
    // 상태를 나타내는 필드
    private int value;

    // private 생성자
    private StatefulSingleton() {}

    // 싱글톤 인스턴스를 반환하는 메서드
    public static StatefulSingleton getInstance() {
        if (instance == null) {
            instance = new StatefulSingleton();
        }
        return instance;
    }

    // 상태 변경 메서드
    public void setValue(int value) {
        this.value = value;
    }

    // 상태를 반환하는 메서드
    public int getValue() {
        return this.value;
    }
}

public class MainApp {
    public static void main(String[] args) {
        // 클라이언트 1: 싱글톤 인스턴스를 가져와서 상태를 설정
        StatefulSingleton client1 = StatefulSingleton.getInstance();
        client1.setValue(42);
        System.out.println("클라이언트 1이 설정한 값: " + client1.getValue());

        // 클라이언트 2: 동일한 싱글톤 인스턴스를 사용해 상태를 변경
        StatefulSingleton client2 = StatefulSingleton.getInstance();
        client2.setValue(100);
        System.out.println("클라이언트 2가 설정한 값: " + client2.getValue());

        // 클라이언트 1이 다시 값을 확인
        System.out.println("클라이언트 1이 다시 확인한 값: " + client1.getValue());
    }
}

• value 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.
• Spring Bean은 항상 무상태(stateless)로 설계를 해야한다. 아주 중요!
  • 특정 클라이언트에 의존적인 필드가 있거나 변경할 수 있으면 안된다.

Layered Architecture

📌 애플리케이션을 세 가지 주요 계층으로 나누어 구조화하는 방법으로 각 계층은 특정한 책임을 갖고 있으며, 계층 간에는 명확한 역할 분담이 이루어져 코드의 재사용성, 유지보수성, 확장성을 높이는 데 도움을 준다.

주요 특징

1. 계층 분리:
   • 시스템을 기능별로 분리하여 모듈화.
2. 책임 분리:
   • 각 계층은 고유한 책임과 역할을 가짐.
3. 상호 의존성:
   • 상위 계층은 하위 계층에만 의존하며, 계층 간의 의존성을 제한.
4. 유지보수 용이:
   • 특정 계층의 변경이 다른 계층에 최소한의 영향을 미침.

Layerd Architecture 개요 

• 기존의 MVC 패턴에서 Controller는 역할이 무수히 많다.
  1. 요청에 대한 처리
  2. 예외처리
  3. View Template 응답 or Data 응답
  4. 비지니스 로직 처리
  5. DB 상호작용
• 문제점
  • Controller에서 요청에 대한 모든 처리를 수행한다. 즉, 책임이 너무 많다.
  • 기능 추가, 수정, 삭제 등의 유지보수가 힘들어진다.
  • 코드의 재사용성이 떨어진다. 메서드로 분리하여도 메서드를 호출하는 중복 코드가 발생한다.

Layered Architecture 구조

• Presentation Layer
  • 사용자의 요청을 받고 응답하는 역할을 수행한다.
  • 화면을 응답하거나 데이터를 응답하는 API를 정의한다.
• Business Layer(Service Layer)
  • 비지니스 로직을 수행한다.
  • 요청을 해석하여 Repository Layer에 전달한다.
  • 일반적으로 하나의 비지니스 로직은 하나의 트랜잭션으로 동작한다.
• Data Access Layer(Repository Layer)
  • 데이터베이스와 연동되어 실제 데이터를 관리한다.
• 용어 설명
  • DTO(Data Transfer Object)
    • 계층간 데이터 전달을 위해 사용되는 객체이다.
  • Model
    • Entity
      • 추후 숙련주차에 배울 JPA와 관련이 있다.
      • JPA에서는 Entity라는 형태로 데이터를 반환한다.
  • DAO(Data Access Object)

계층 간 의존성

• 상위 계층은 하위 계층에만 의존합니다.
• 계층 간의 의존성을 단방향으로 제한하여 결합도를 낮춥니다.

계층 간 의존성 예시

Presentation → Application → Domain → Data Access

장점

1. 유지보수성:
   • 계층별 역할이 분리되어, 특정 계층의 변경이 다른 계층에 미치는 영향을 최소화.
2. 재사용성:
   • 서비스나 데이터 계층을 다른 애플리케이션에서도 재사용 가능.
3. 테스트 용이성:
   • 계층 단위로 테스트가 가능하여, 단위 테스트와 통합 테스트를 쉽게 수행.
4. 확장성:
   • 특정 계층에 새로운 기능을 추가하거나 변경하기 쉬움.

단점

1. 복잡성 증가:
   • 계층 간의 통신 코드로 인해 초기 개발이 복잡해질 수 있음.
2. 성능 문제:
   • 계층 간 호출이 많아지면 성능 저하 가능.
3. 단순 CRUD에 과한 구조:
   • 작은 애플리케이션에서는 계층형 아키텍처가 불필요한 복잡성을 초래.

계층형 아키텍처를 사용할 때 적합한 경우

1. 복잡한 비즈니스 로직:
   • 다양한 데이터 소스와 복잡한 비즈니스 규칙이 있는 애플리케이션.
2. 협업 프로젝트:
   • 역할 분리가 명확해 팀 간 작업이 효율적.
3. 대규모 애플리케이션:
   • 변경 사항을 쉽게 관리하고, 시스템 확장이 필요한 경우.

Layered Architecture 적용

1. Controller

• 클라이언트의 요청을 받는 역할을 수행한다.
• 요청에 대한 처리를 Service Layer에 전달한다.
• Service에서 처리 완료된 결과를 클라이언트에 응답한다.
• 사용하는 Annotation : @Controller, @RestController

2. Service

• 사용자의 요청 사항을 처리한다.
• DB와 상호작용이 필요한 경우, Repository Layer에게 요청한다.
• 사용하는 Annotation: @Service

3. Repository

• DB와 상호작용을 수행한다.
  • Connection 연결, 해제
  • CRUD 작업 처리
• 사용하는 Annotation: @Repository

4. DTO(Data Transfer Object)

• 계층간 데이터 전달을 위해 사용된다.
• 요청 데이터를 처리하는 객체는 일반적으로 RequestDto로 명명한다.
• 응답 데이터를 처리하는 객체는 일반적으로 ResponseDto로 명명한다.

DTO (Data Transfer Object)

📌 애플리케이션에서 계층 간 데이터 전송을 목적으로 사용하는 단순한 객체입니다.

• 주로 데이터를 전송하기 위한 속성과 Getter/Setter 메서드만 포함하며, 비즈니스 로직을 포함하지 않습니다.

DTO의 주요 역할

1. 데이터 캡슐화:
   • 데이터 구조를 명확히 정의하여 계층 간 데이터 교환을 표준화.
2. 안전한 데이터 전달:
   • 데이터 모델(Entity)과 직접 연관되지 않아, 민감한 데이터 보호 가능.
3. 데이터 변환 및 제한:
   • 클라이언트가 필요로 하는 데이터만 전달하도록 제한.
4. API 설계에 유용:
   • RESTful API에서 응답(Response) 또는 요청(Request) 데이터를 정의.

DTO의 구조

DTO는 일반적으로 다음과 같은 형태로 작성됩니다:

• 속성 필드
• Getter/Setter 메서드
• (선택적) 생성자, toString(), equals(), hashCode()

public class UserDTO {
    private Long id;
    private String name;
    private String email;

    // 기본 생성자
    public UserDTO() {}

    // 생성자
    public UserDTO(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    // Getter와 Setter
    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }
}

DTO의 사용 예

a. 요청(Request) DTO

클라이언트가 서버에 데이터를 보낼 때 사용.

Request DTO 예제

public class CreateUserRequest {
    private String name;
    private String email;

    // Getter와 Setter
}

Controller

@RestController
@RequestMapping("/users")
public class UserController {

    @PostMapping
    public ResponseEntity<String> createUser(@RequestBody CreateUserRequest request) {
        // 요청 데이터 처리
        return ResponseEntity.ok("User created: " + request.getName());
    }
}

요청 데이터

{
    "name": "John Doe",
    "email": "john.doe@example.com"
}

b. 응답(Response) DTO

서버가 클라이언트에 데이터를 반환할 때 사용.

Response DTO 예제

public class UserResponse {
    private Long id;
    private String name;
    private String email;

    public UserResponse(Long id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    // Getter만 제공
}

Controller

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
        // 서비스에서 가져온 데이터
        UserResponse response = new UserResponse(id, "John Doe", "john.doe@example.com");
        return ResponseEntity.ok(response);
    }
}

응답 데이터

{
    "id": 1,
    "name": "John Doe",
    "email": "john.doe@example.com"
}

Entity와 DTO의 차이

DTO 변환 (Entity ↔ DTO)

DTO는 Entity와 직접적으로 사용되지 않으며, 변환 과정을 거칩니다.

Service 계층에서 변환 예

@Service
public class UserService {

    public UserResponse getUserResponse(UserEntity entity) {
        return new UserResponse(
            entity.getId(),
            entity.getName(),
            entity.getEmail()
        );
    }
}

Spring Boot에서 DTO 자동 변환

Spring Boot에서 DTO 변환을 쉽게 하기 위해 ModelMapper 또는 MapStruct와 같은 라이브러리를 사용할 수 있습니다.

a. ModelMapper 예제

의존성 추가 (Maven)

<dependency>
    <groupId>org.modelmapper</groupId>
    <artifactId>modelmapper</artifactId>
    <version>3.1.0</version>
</dependency>

변환 코드

import org.modelmapper.ModelMapper;

@Service
public class UserService {

    private final ModelMapper modelMapper = new ModelMapper();

    public UserDTO convertToDTO(UserEntity entity) {
        return modelMapper.map(entity, UserDTO.class);
    }
}

DTO의 장점

1. 데이터 보호:
   • 데이터베이스와 직접 연결된 Entity를 노출하지 않아 민감한 데이터 보호.
2. 역할 분리:
   • Entity와 DTO를 분리하여 비즈니스 로직과 데이터 전송 책임을 명확히 구분.
3. API 표준화:
   • 클라이언트 요청과 응답 형식을 명확히 정의 가능.
4. 유지보수성 향상:
   • 데이터 전송 형식 변경이 Entity와 독립적으로 이루어짐.

결론

• DTO(Data Transfer Object)는 계층 간 데이터를 주고받을 때 사용되는 단순한 객체입니다.
• 데이터 캡슐화, 보안성 강화, API 설계 표준화 등의 장점으로, 특히 Spring MVC와 RESTful API 설계에서 널리 사용됩니다.
• DTO를 활용하여 애플리케이션의 구조를 더 유연하고 유지보수 가능하게 설계할 수 있습니다.

정적 리소스

📌 웹 애플리케이션에서 변하지 않는 파일들을 의미한다. 예를 들어, HTML, CSS, JavaScript, 이미지 파일들(JPG, PNG, GIF) 등이 정적 리소스에 해당한다.

• 정적인 HTML, CSS, JS, Image 등을 변경 없이 그대로 반환한다.

정적 리소스의 특징

1. 고정된 내용:
   • 요청이 올 때마다 동일한 콘텐츠를 제공합니다.
   • 실행되거나 동적으로 변환되지 않습니다.
2. 캐싱 가능:
   • 정적 리소스는 자주 요청되므로 브라우저에서 캐싱하여 성능을 최적화할 수 있습니다.
3. 서버 부담 감소:
   • 서버는 정적 리소스를 변환하거나 처리하지 않으므로, 부하가 적습니다.
4. 브라우저에서 직접 렌더링:
   • 클라이언트(브라우저)가 직접 처리할 수 있는 파일 형식으로 제공됩니다.

Spring Boot에서 정적 리소스 제공

• Spring Boot는 기본적으로 정적 리소스를 제공하기 위한 구조를 내장하고 있습니다.

1. 정적 리소스 경로

Spring Boot는 다음 디렉토리에서 정적 리소스를 자동으로 로드합니다:

2. 정적 리소스 예제

정적 리소스와 동적 리소스 비교

정적 리소스와 컨트롤러 경로 충돌

Spring Boot는 기본적으로 정적 리소스를 우선 처리합니다.
예:

• /index.html 정적 파일이 있으면, 해당 파일을 반환.
• /index를 처리하는 컨트롤러가 있다면, 정적 리소스 대신 컨트롤러가 처리.

컨트롤러 우선 처리

application.properties에서 다음 설정으로 컨트롤러를 우선 처리하도록 변경 가능합니다:

spring.mvc.static-path-pattern=/**

정적 리소스 최적화

1. Gzip 압축:
   • 정적 리소스를 Gzip으로 압축하여 전송 속도를 개선.
   properties

    

    
2. Content Delivery Network (CDN):
   • 정적 리소스를 CDN에 배포하여 전 세계적으로 빠르게 제공.
3. 캐싱:
   • 브라우저 캐싱을 활용하여 불필요한 네트워크 요청을 줄임.

server.compression.enabled=true
server.compression.mime-types=text/html,text/xml,text/plain,text/css,application/javascript

요약

• 정적 리소스는 서버가 변경 없이 그대로 반환하는 콘텐츠입니다.
• Spring Boot는 /static, /public 등 기본 경로에서 정적 리소스를 자동으로 제공합니다.
• 정적 리소스는 속도가 빠르고 서버 부하가 적으므로, 이미지, CSS, JS 등의 파일 전송에 최적입니다.
• 필요 시 경로와 캐싱 설정을 커스터마이징할 수 있습니다.

• Spring Boot의 정적 리소스 경로
  • 아래 경로들에 정적 리소스가 존재하면 서버에서 별도의 처리 없이 파일 그대로 반환된다.
  1. /static
  2. /public
  3. /META-INF/resources
  4. src/main/resources
     1. /static

Spring Boot Directory 구조

• src/main/resources/static/hello/world.html 디렉토리 구조라면
  • http://localhost:8080/hello/world.html URL로 리소스에 접근이 가능하다.
  • /static 대신 /public 혹은 /META-INF/resources 도 사용 가능하다.

View Template (동적 리소)

📌 웹 애플리케이션에서 서버가 클라이언트에 응답으로 제공할 HTML 페이지를 동적으로 생성하기 위해 사용하는 템플릿 파일입니다. 데이터를 표시하기 위해 동적인 콘텐츠와 정적인 HTML 구조를 결합하는 데 사용됩니다.

• Spring에서는 Thymeleaf, JSP와 같은 템플릿 엔진을 사용해 View Template을 작성할 수 있고, View Template은 서버에서 데이터를 받아 이를 HTML 구조에 맞게 삽입한 후, 최종적으로 클라이언트에게 전송되는 HTML 문서로 변환하여 사용자에게 동적으로 생성된 웹 페이지를 제공한다.
• 📌 View Template
  • View Template은 Model을 참고하여 HTML 등이 동적으로 만들어지고 Client에 응답된다.
  • Spring Boot는 기본적으로 View Template 경로(src/main/resources/templates)를 설정한다.
  • build.gradle에 Thymeleaf 의존성을 추가하면 ThymeleafViewResolver와 필요한 Spring Bean들이 자동으로 등록된다. 
• SSR(Server Side Rendering)을 사용할 때 View가 반환된다.

View Template의 역할

• 정적 HTML과 동적 데이터 결합:
  • 서버에서 HTML 파일에 동적 데이터를 삽입하여 사용자 맞춤 콘텐츠를 생성.
• 서버 사이드 렌더링 (SSR):
  • 브라우저에 표시될 HTML을 서버에서 렌더링하고 클라이언트로 전송.
• UI 레이아웃 관리:
  • 레이아웃, 반복 구조, 조건부 표시 등과 같은 동적 UI 요소를 효율적으로 관리.

Spring MVC에서 View Template

Spring MVC에서는 Model-View-Controller 패턴을 기반으로 View Template 엔진을 사용하여 HTML을 생성합니다.

Spring MVC에서의 동작 흐름

1. Controller:
   • 클라이언트의 요청을 처리하고, 데이터를 Model 객체에 담아 View로 전달.
2. View Template:
   • Model 데이터를 기반으로 HTML을 렌더링.
3. Client:
   • 완성된 HTML 페이지를 클라이언트로 전송하여 브라우저에 표시.

pring Boot에서 지원하는 View Template 엔진

Thymeleaf 예제 (Spring Boot 기본 설정)

a. Maven 의존성 추가

Spring Boot Starter를 사용하면 Thymeleaf가 기본적으로 포함됩니다:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

b. 프로젝트 구조

c. Controller 코드

@Controller
public class HomeController {

    @GetMapping("/")
    public String home(Model model) {
        model.addAttribute("title", "Welcome to Thymeleaf");
        model.addAttribute("message", "Hello, Thymeleaf!");
        return "home"; // home.html을 렌더링
    }
}

d. Thymeleaf View Template (home.html)

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <title th:text="${title}">Default Title</title>
</head>
<body>
    <h1 th:text="${message}">Default Message</h1>
</body>
</html>

결과

1. 클라이언트가 /로 요청.
2. Controller가 Model에 데이터를 담아 home.html로 전달.
3. Thymeleaf가 데이터를 HTML에 삽입.
4. 클라이언트로 다음과 같은 HTML 응답이 전송:

<!DOCTYPE html>
<html>
<head>
    <title>Welcome to Thymeleaf</title>
</head>
<body>
    <h1>Hello, Thymeleaf!</h1>
</body>
</html>

@Controller의 응답으로 String을 반환하는 경우

• @ResponseBody 가 없으면 View Resolver가 실행되며 View를 찾고 Rendering한다.

@Controller
public class ViewTemplateController {
	
	@RequestMapping("/response-view")
  public String responseView(Model model) {
      // key, value
      model.addAttribute("data", "sparta");

      return "thymeleaf-view";
  }
	
}

<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>Hello</title>
</head>
<body>
    <h1>Thymeleaf</h1>
    <h2 th:text="${data}"></h2>
</body>
</html>

ex) http://localhost:8080/response-view

• @ResponseBody 가 있으면 HTTP Message Body에 return 문자열 값이 입력된다.

반환 타입이 void인 경우

• 잘 사용하지 않는다.
• @Controller + (@ResponseBody, HttpServletResponse, OutputStream)과 같은 HTTP Message Body를 처리하는 파라미터가 없으면 RequestMapping URL을 참고하여 View Name으로 사용한다.

@Controller
public class ViewTemplateController {
	
	// thymeleaf-view.html 과 Mapping된다.
  @RequestMapping("/thymeleaf-view")
  public void responseViewV2(Model model) {
      model.addAttribute("data", "sparta");
  }
	
}

• 예시와 같은 경우에는 viewTemplate(viewName)을 RequestMapping URL 주소로 찾는다.

HTTP Message Body

📌 HTTP Message Body는 HTTP 요청(Request) 또는 응답(Response)에서 실제 데이터를 담는 부분입니다.

• REST API를 만드는 경우 Server에서 Client로 HTML을 전달하는 방식이 아닌 HTTP Message Body에 직접 Data를 JSON 형식으로 담아 전달한다.
• 정적 HTML, View Template 또한 HTTP Message Body에 담겨서 전달된다. 현재 설명하는 Response의 경우는 정적 HTML, View Template을 거치지 않고 직접 HTTP Response Message를 만들어 전달하는 경우를 말하는것.

HttpServletResponse 사용

@Controller
public class ResponseBodyController {
	
	@GetMapping("/v1/response-body")
	public void responseBodyV1(
														HttpServletResponse response
													) throws IOException {
		
		response.getWriter().write("data");
	
	}
}

• Response Body에 data 라는 문자열이 입력되어 응답된다.
• 기존 Servlet을 다룰 때 코드와 형태가 같다.

ResponseEntity<> 사용

@GetMapping("/v2/response-body")
public ResponseEntity<String> responseBodyV2() {
		
	return new ResponseEntity<>("data", HttpStatus.OK);
}

• Response Body에 data라는 문자열과 HttpStatus.OK에 해당하는 상태 코드를 반환한다.
• ResponseEntity는 HttpEntity 를 상속받았다.
  • HttpEntity는 HTTP Message의 Header, Body 모두 가지고 있다.

@ResponseBody(TEXT, JSON) 사용

@Data
@NoArgsConstructor // 기본 생성자
@AllArgsConstructor // 전체 필드를 인자로 가진 생성자
public class Tutor {

    private String name;
    private int age;

}

// TEXT 데이터 통신
@ResponseBody
@GetMapping("/v3/response-body-text")
public String responseBodyText() {
		
	return "data"; // HTTP Message Body에 "data"
}

// JSON 데이터 통신
@ResponseBody
@GetMapping("/v3/response-body-json")
public Tutor responseBodyJson() {
		
	Tutor tutor = new Tutor("wonuk", 100);
		
	return tutor; // HTTP Message Body에 Tutor Object -> JSON
}

• View를 사용하는 것이 아닌 HTTP Message Converter를 통해 HTTP Message Body를 직접 입력할 수 있다. → ResponseEntity와 같음
• @ResponseStatus 를 사용하여 상태 코드를 지정할 수 있다.

@ResponseStatus(HttpStatus.OK)
@ResponseBody
@GetMapping("/v4/response-body")
public Tutor responseBodyV4() {
		
	Tutor tutor = new Tutor("wonuk", 100);
		
	return tutor;
}

• 단, 응답 코드를 조건에 따라서 동적으로 변경할 수는 없다.

ex) 1번의 경우 OK, 2번의 경우 Created

ResponseEntity<Object>(JSON)

@ResponseBody
@GetMapping("/v5/response-body")
public ResponseEntity<Tutor> responseBody() {
		
	Tutor tutor = new Tutor("wonuk", 100);
	
	return new ResponseEntity<>(tutor, HttpStatus.OK);
}

• ResponseEntity<>두 번째 파라미터에 Enum을 사용하여 상태 코드를 바꿀 수 있다.
• HTTP Message Converter를 통하여 JSON 형태로 변환되어 반환된다.
• 동적으로 응답 코드를 변경할 수 있다.

@ResponseBody
@GetMapping("/v5/response-body")
public ResponseEntity<Tutor> responseBody() {
		
	Tutor tutor = new Tutor("wonuk", 100);
	
	if (조건) {
		return new ResponseEntity<>(tutor, HttpStatus.OK);
	} else {
		return new ResponseEntity<>(tutor, HttpStatus.BAD_REQUEST);
	}
	
}

• HttpEntity를 상속받았다.

정리

Client에서 Server로 Data를 전달하는 세가지 방법

1. GET - Query Param, Query String

ex) http://localhost:8080/tutor?name=wonuk&age=100

• 사용하는 어노테이션
  • @RequestParam, @ModelAttribute

1. POST - HTML Form(x-www-form-urlencoded)

POST /form-data
content-type: application/x-www-form-urlencoded

**key1=value1&key2=value2**

• 사용하는 어노테이션
  • @RequestParam, @ModelAttribute

1. HTTP Request Body

ex) 데이터(JSON, TEXT, XML 등)를 직접 HTTP Message Body에 담아서 사용한다.

• 사용하는 어노테이션
  • @RequestBody

Server(Spring)에서 HTTP 응답을 Client에 전달하는 세가지 방법

1. 정적 리소스
   • 정적인 HTML, CSS, JS, Image 등을 변경없이 그대로 반환한다.

1. View Template
   • SSR(Server Side Rendering)을 사용할 때 View가 반환된다.
   • 사용하는 어노테이션
     • @Controller
      

1. HTTP Message Body
   • 응답 데이터를 직접 Message Body에 담아 반환한다.
   • 사용하는 어노테이션
     • @ResponseBody, ResponseEntity<Object>
      

• 요청
  • @RequestParam, @ModelAttribute, @RequestBody
• 응답
  • 정적 리소스, View Template(@Controller), @ResponseBody, ResponseEntity<Object>

JSON

📌 데이터를 표현하기 위한 가볍고 간단한 텍스트 기반의 데이터 교환 형식입니다. 키-값 쌍으로 데이터를 구조화하며, 사람과 기계가 읽고 쓰기 쉽도록 설계되었습니다. 웹 애플리케이션과 서버 간의 데이터 교환에서 널리 사용됩니다.

• Json은 @RestController 에서 가장 많이 사용되는 데이터 형식이다. 현재 대부분의 API는 Request, Response 모두 JSON 형태로 통신한다.
• Json 형태로 Data를 전송할 때는 Request Header의 content-type이 꼭 application/json 이여야 한다.

JSON의 특징

1. 가독성:
   • 간단한 문법으로 사람이 읽기 쉽습니다.
2. 경량성:
   • XML에 비해 데이터 표현이 간결하여 네트워크 트래픽이 적습니다.
3. 언어 독립성:
   • 대부분의 프로그래밍 언어에서 JSON을 쉽게 생성하고 파싱할 수 있습니다.
4. 구조화된 데이터 표현:
   • 객체, 배열, 숫자, 문자열 등 다양한 데이터 타입을 지원합니다.

JSON의 데이터 타입

JSON 처리 (Java 예제)

a. Java 객체 → JSON 변환

Spring Boot에서 Jackson 라이브러리를 사용하여 JSON 데이터를 처리할 수 있습니다.

import com.fasterxml.jackson.databind.ObjectMapper;

public class JsonExample {
    public static void main(String[] args) throws Exception {
        ObjectMapper objectMapper = new ObjectMapper();

        // 객체 생성
        User user = new User("John", 30);

        // 객체를 JSON으로 변환
        String json = objectMapper.writeValueAsString(user);
        System.out.println(json);
    }
}

class User {
    private String name;
    private int age;

    // Constructor, Getters, Setters
    public User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    // Getters and Setters
}

JSON과 XML 비교

JSON의 장점

1. 간단하고 가볍다:
   • 데이터 표현이 직관적이고 XML에 비해 크기가 작음.
2. 언어 독립적:
   • JavaScript뿐만 아니라 Python, Java, PHP 등 다양한 언어에서 지원.
3. API 표준:
   • RESTful API에서 사실상의 표준 형식으로 사용.

JSON 요청

1. HttpServletRequest 사용

더보기

@Data
public class Tutor {
	private String name;
	private int age;
}

@RestController
public class JsonController {
	
	private ObjectMapper objectMapper = new ObjectMapper();

	@PostMapping("/v1/request-body-json")
	public void requestBodyJsonV1(
				HttpServletRequest request, 
				HttpServletResponse response
	) throws IOException {

		// request body message를 Read
		ServletInputStream inputStream = request.getInputStream();
		// UTF-8 형식의 String으로 변환한다.
		String requestBody = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);

		// String requestBody를 ObjectMapper를 사용하여 변환 "{\"name\":\"wonuk\", \"age\":10}"
		Tutor tutor = objectMapper.readValue(requestBody, Tutor.class);
		
		// 응답
		response.getWriter().write("tutor" + tutor);
	}
}

• Postman
  • Content-Type 헤더 확인 : application/json

 

• HttpServletRequest를 사용하여 HTTP Message Body 데이터를 Read하여 문자로 변환한다.
• 문자로 만들어진 JSON을 Jackson 라이브러리의 objectMapper를 사용하여 Object로 변환

 

 

 

 

 

 

 

2. @RequestBody 사용

더보기

@RestController
public class JsonController {
	
	private ObjectMapper objectMapper = new ObjectMapper();

	@PostMapping("/v2/request-body-json")
  public String requesBodytJsonV2(@RequestBody String requestBody) throws IOException {

      Tutor tutor = objectMapper.readValue(requestBody, Tutor.class);

      return "tutor.getName() = " + tutor.getName() + "tutor.getAge() = " + tutor.getAge();
  }
    
}

@RequestBody를 사용하여 HTTP Request Body의 Data에 접근한다.

3. ObjectMapper 제거

더보기

@RestController
public class JsonController {
	
	@PostMapping("/v3/request-body-json")
	public String requestBodyJsonV3(@RequestBody Tutor tutor) {
		
		Tutor requestBodyTutor = tutor;

		return "tutor = " + requestBodyTutor;
	}
}

 

위 Controller가 동작하는 이유는 무엇인가요?

• @RequestBody
  • @RequestBody 어노테이션을 사용하면 Object를 Mapping할 수 있다.
  • HttpEntity<>, @RequestBody를 사용하면 HTTPMessageConverter가 Request Body의 Data를 개발자가 원하는 String이나 Object로 변환해준다.
  • JSON to Object의 Mapping 또한 가능하다.
    • MappingJackson2HttpMessageConverter 의 역할
    • 쉽게 설명하면 HTTP Message Converter가 ObjectMapper를 대신 실행한다.

4. @RequestBody는 생략할 수 없다.

더보기

@RequstParam, @ModelAttribute는 생략이 가능하다.

 

@Slf4j
@RestController
public class JsonController {
	
	@PostMapping("/v4/request-body-json")
  public String requestBodyJsonV4(Tutor tutor) { // @RequestBody 생략시 @ModelAttribute가 된다.

      Tutor requestBodyTutor = tutor;

      return "tutor.getName() = " + requestBodyTutor.getName() + " tutor.getAge() = " + requestBodyTutor.getAge();
  }
	
}

• 생략하면 @ModelAttribute가 된다.
  • 요청 파라미터를 처리하도록 설정된다.
• Request Header의 contentType은 꼭 application/json 이여야 한다.
  • 위 설정 정보를 기반으로 MessageConverter가 실행된다.

 

5. HttpEntity 사용

더보기

@RestController
public class JsonController {
	
	@PostMapping("/v5/request-body-json")
  public String requestBodyJsonV5(
          HttpEntity<Tutor> httpEntity
  ) {
      // 값을 꺼내서 사용해야한다!
      Tutor tutor = httpEntity.getBody();

      return "tutor.getName() = " + tutor.getName() + " tutor.getAge() = " + tutor.getAge();
  }
	
}

 

• HttpEntity<Tutor>
  • Generic Type으로 Tutor가 지정되어 있기 때문에 해당 Class로 반환된다.

 

6. @ResponseBody

더보기

@Controller
public class JsonController {
	
	@ResponseBody // @RestController = @Controller + @ResponseBody
	@PostMapping("/v6/request-body-json")
    public Tutor requestJson(@RequestBody Tutor tutor) {
        return tutor;
  }
	
}

 

• View를 조회하지 않고 Response Body에 Data를 입력해서 직접 반환한다.
• 요청 뿐만이 아니라 응답에도 HttpMessageConverter가 동작한다.
  • MaapingJackson2HttpMessageConverter 적용
  • 응답 객체인 Tutor가 JSON으로 변환되어 반환된다.
• HttpEntity를 사용해도 된다.

요약

1. 요청 데이터는 @RequestBody를 사용해서 바인딩 하면 된다.
2. @RequestBody 는 생략이 불가능하다.
   • @ModelAttribute가 적용되기 때문
3. HttpMessageConverter 가 요청 응답 데이터를 모두 변환할 수 있다.
   • JSON은 MappingJackson2HttpMessageConverter 를 사용한다.
   • Request Header의 Content-Type은 application/json 이어야 한다.
     • Header로 어떤 Converter가 동작할지 판별한다.

쿼리 파라미터(Query Parameter)

📌 HTTP 요청 URL의 일부로, Key-Value 형태로 데이터를 전달하는 방법

• 쿼리 파라미터는 URL 경로 끝에 **?**로 시작하며, 여러 개의 파라미터는 **&**로 구분됩니다.

구조
<URL>?<key1>=<value1>&<key2>=<value2>

특징

1. 클라이언트가 서버로 데이터를 전달할 때 사용.
2. GET 요청에서 주로 사용되며, 요청 URL에 데이터를 포함.
3. 데이터가 URL에 노출되므로 민감한 정보를 보내는 데 적합하지 않음.
4. 여러 파라미터를 전달할 수 있음.

HTML 폼 데이터(Form Data)

📌 HTML 폼(Form)을 통해 서버로 전달되는 Key-Value 형태의 데이터입니다.

• 폼 데이터는 주로 POST 요청의 HTTP 요청 본문(body)에 포함됩니다.

구조

HTML 폼을 통해 데이터를 보낼 때, Key-Value 쌍으로 데이터를 전달합니다. 데이터는 HTTP 요청 본문에 포함되거나, GET 요청의 경우 쿼리 파라미터로 전송됩니다.

특징

1. POST 요청에서 주로 사용되며, 데이터가 HTTP 요청 본문에 포함.
2. GET 요청에서는 폼 데이터가 쿼리 파라미터로 전달.
3. 데이터를 숨길 수 있으나, 민감한 데이터는 암호화(HTTPS) 필요.
4. 주로 사용자 입력 데이터를 서버로 전달할 때 사용.

HTML 폼 예제

<form action="/submit" method="POST">
    <label for="name">Name:</label>
    <input type="text" id="name" name="name">
    
    <label for="email">Email:</label>
    <input type="email" id="email" name="email">
    
    <button type="submit">Submit</button>
</form>

POST 요청 본문 예시:

name=John&email=john.doe@example.com

Spring 컨트롤러에서 처리:

@PostMapping("/submit")
public String handleForm(
    @RequestParam String name,
    @RequestParam String email) {
    return "Name: " + name + ", Email: " + email;
}

쿼리 파라미터와 폼 데이터의 차이

예제 비교

쿼리 파라미터

GET /search?keyword=spring&category=books

폼 데이터

POST /submit
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

name=John&email=john.doe@example.com

결론

• 쿼리 파라미터는 주로 GET 요청에서 사용되며, URL에 간단한 데이터를 전달.
• 폼 데이터는 주로 POST 요청에서 사용되며, 대량의 사용자 입력 데이터를 서버로 보낼 때 적합.

@RequestParam

📌 HTTP 요청의 쿼리 파라미터(Query Parameter)나 HTML 폼 데이터(Form Data)를 컨트롤러 메서드의 매개변수로 매핑하는 데 사용됩니다. 주로 클라이언트가 요청 시 전달하는 Key-Value 형식의 데이터를 처리할 때 사용됩니다.

• URL에서 파라미터 값과 이름을 함께 전달하는 방식으로 주로 HTTP 통신 Method 중 GET 방식의 통신을 할 때 많이 사용한다. @Requestparam을 사용하면 요청 파라미터 값에 아주 쉽고 간편하게 접근(Parameter Binding)할 수 있습니다.
• ?뒤에 오는 URL을 Query String, Query Parameter, Request Param이라 합니다.
• GET 요청에서 쿼리 파라미터를 처리하거나, POST 요청에서 폼 데이터를 처리하는 데 사용됩니다.

사용 목적

• 쿼리 파라미터(Query Parameter):
  • URL에 포함된 Key-Value 형식의 데이터를 매핑.
  • 예: GET /api/search?keyword=spring
• 폼 데이터(Form Data):
  • HTML 폼을 통해 전송된 데이터를 매핑.
  • 예: POST 요청 본문에 name=John&email=john.doe@example.com 데이터가 포함.

주요 속성

@RequestParam과 다른 어노테이션 비교

주의 사항

1. 필수 속성 처리:
   • 기본적으로 @RequestParam은 요청 파라미터가 없으면 에러를 발생시킵니다.
     필요한 경우 required = false를 명시하거나, defaultValue를 설정하세요.
2. 타입 변환:
   • Spring은 문자열 값을 기본적으로 매핑하며, 필요한 경우 자동으로 타입 변환을 지원합니다.
     단, 변환할 수 없는 타입이 지정되면 예외가 발생합니다.

@Slf4j
@Controller
public class RequestParamControllerV2 {

	@ResponseBody
	@GetMapping("/v1/request-param")
	public String requestParamV1 (
					@RequestParam("name") String userName,
					@RequestParam("age") int userAge													
	) {
		// logic
		log.info("name={}", userName);
    log.info("age={}", userAge);
		return "success";
	}

}

1. @Controller + @ResponseBody
   • View를 찾는 것이 아니라 ResponseBody에 응답을 작성한다(=@RestController)
2. @RequestParam
   • 파라미터 이름으로 바인딩한다.
3. @RequestParam(”속성값”)
   • 속성값이 파라미터 이름으로 매핑된다.

“속성값”과 변수명이 같으면 생략이 가능하다.

ex) @RequestParam("name") String name

// GET http://localhost:8080/v2/request-param?name=sparta&age=100
@ResponseBody
@GetMapping("/v2/request-param")
public String requestParamV2 (
				@RequestParam String name,
				@RequestParam int age													
) {
	// logic
	log.info("name={}", name);
  log.info("age={}", age);
	return "success";
}

@RequestParam 사용법

1. 어노테이션, 속성값 모두 생략

• @RequestParam은 생략이 가능하다.

// GET http://localhost:8080/v3/request-param?name=sparta&age=100
@ResponseBody
@GetMapping("/v3/request-param")
public String requestParamV3 (
				String name,
				int age													
) {
	// logic
	log.info("name={}", name);
  log.info("age={}", age);
	return "success";
}

• 생략하면 @RequestParam(required=false) 필수 여부 속성이 default로 설정된다.
• 단, 요청 파라미터와 이름이 완전히 같아야 한다.
• 단순 타입(int, String, Integer 등)이어야 한다.

2. required 속성 설정

• 파라미터의 필수 값을 설정한다.
• API 스펙을 규정할 때 사용한다.

@ResponseBody
@GetMapping("/v4/request-param")
public String requestParam (
				@RequestParam(required = true) String name, // 필수
				@RequestParam(required = false) int age	// 필수가 아님										
) {
	// logic
	log.info("name={}", name);
  log.info("age={}", age);
	return "success";
}

• @RequestParam을 사용하면 기본 Default값은 True이다.
  • True로 설정된 파라미터 값이 요청에 존재하지 않으면 400 BadRequest(클라이언트 측 에러)
• Exception이 발생하지 않는 경우

ex) http://localhost:8080/v4/request-param?name=sparta&age=100

• Exception이 발생하는 경우

ex) http://localhost:8080/v4/request-param?age=100

ex) http://localhost:8080/v4/request-param

• required = false 설정이 되어있으면 해당 파라미터는 없어도 된다.
  • 주의! http://localhost:8080/v4/request-param?name=sparta 요청한다면?

• 500 Error가 발생한다.
• int Type에는 null을 넣을 수 없다. 0이라도 들어가야 한다.

따라서 보통 null을 허용하는 Integer로 사용하거나 default 옵션을 사용한다.

@ResponseBody
@GetMapping("/v4/request-param")
public String requestParam (
				@RequestParam(required = true) String name, // 필수
			  @RequestParam(required = false) Integer age										
) {
	// logic
	log.info("name={}", name);
  log.info("age={}", age);
	return "success";
}

• 파라미터 Key값만 있고 Value가 없는 경우 http://localhost:8080/request-param?name=

• null과 빈 문자열 “”은 다르다!
• 위 형태는 빈 문자열 “” 로 인식한다, True지만 통과가 되어버린다. 주의해야 한다.

3. default 속성 적용

• 파라미터의 기본 값을 설정한다.

@ResponseBody
@GetMapping("/v5/request-param")
public String requestParam (
				@RequestParam(required = true, defaultValue = "sparta") String name,
		    @RequestParam(required = false, defaultValue = "1") int age											
) {
	// logic
	log.info("name={}", name);
  log.info("age={}", age);
	return "success"	
}

• name Parameter 의 값이 없으면 기본적으로 “sparta”으로 설정한다

ex) http://localhost:8080/v5/request-param?age=100

• age Parameter의 값이 없으면 기본적으로 1 으로 설정한다.

ex) http://localhost:8080/v5/request-param?name=wonuk

ex) http://localhost:8080/v5/request-param

• 주의! defaultValue 속성을 설정하게 되면 “” 빈 문자열의 경우에도 기본 값이 설정된다.

ex) http://localhost:8080/v5/request-param?name&age

4. Map 사용

• Parameter를 Map형태로 조회가 가능하다.

@ResponseBody
@GetMapping("/v6/request-param")
public String requestParamV6(
        @RequestParam Map<String, String> map
) {
    // logic
    log.info("name={}", map.get("name"));
    log.info("age={}", map.get("age"));

    return "success";
}

• Map 형태(key=value)로 조회가 가능하다

ex) http://localhost:8080/v6/request-param?name=sparta&age=100

• MultiValueMap 형태(key=[value1, value2])로 조회가 가능하다.

@ResponseBody
@GetMapping("/v6/request-param")
public String requestParamV6(
        @RequestParam MultiValueMap<String, String> map
) {
    // logic
    log.info("name={}", map.get("name"));
    log.info("age={}", map.get("age"));

    return "success";
}

• ex) http://localhost:8080/v6/request-param?
• name=sparta&name=wonuk&name=tutor&age=100

@ModelAttribute

📌 HTTP 요청 데이터(Form 데이터, 쿼리 파라미터 등)를 객체에 바인딩하거나, 뷰에 데이터를 전달하는 데 사용됩니다.

• 요청 파라미터를 받아 필요한 Object로 바인딩 해준다. 주로 HTML 폼에서 전송된 데이터를 바인딩하고 HTTP Method POST인 경우 사용된다.
• 매개변수에 사용: 요청 데이터를 객체로 매핑.
• 메서드에 사용: 뷰에 공통 데이터를 추가.

주요 역할

1. 요청 데이터를 객체로 바인딩

• 클라이언트에서 전달된 **요청 데이터(쿼리 파라미터, 폼 데이터)**를 자동으로 객체 필드에 바인딩합니다.
• 주로 POST 요청의 폼 데이터를 처리할 때 사용됩니다.

2. 뷰(View)에 데이터 전달

• 컨트롤러 메서드에서 반환 값이 아닌, 뷰에 데이터를 추가합니다.
• 뷰에 공통적으로 전달해야 하는 데이터를 설정할 때 유용합니다.

특징 및 동작

1. 객체 생성 및 데이터 바인딩

• Spring은 @ModelAttribute를 사용하면 다음 단계를 수행합니다:
  1. 지정된 클래스의 객체를 생성합니다.
  2. 요청 데이터(쿼리 파라미터, 폼 데이터)를 객체 필드에 매핑합니다.

2. 요청 방식에 따른 동작

• GET 요청: 객체를 초기화하거나 뷰에 데이터를 전달.
• POST 요청: 폼 데이터를 객체에 바인딩.

3. 생략 가능

• @ModelAttribute는 생략 가능하며, 매개변수가 사용자 정의 객체라면 Spring이 자동으로 @ModelAttribute를 적용합니다.

주요 속성

주의 사항

1. 필드 이름 매칭:
   • 요청 데이터의 Key와 객체 필드 이름이 동일해야 바인딩됩니다.
   • Key와 필드 이름이 다르면 바인딩되지 않습니다.
2. 유효성 검증:
   • @Valid와 함께 사용하여 요청 데이터를 검증할 수 있습니다
3. 중복 데이터 처리:
   • 동일한 이름의 데이터를 여러 메서드에서 설정하면, 마지막으로 설정된 데이터가 우선합니다.

@PostMapping("/register")
public String registerUser(@Valid @ModelAttribute User user, BindingResult result) {
    if (result.hasErrors()) {
        return "form";
    }
    return "success";
}

기존 코드

@Data는 @Getter, @Setter, @ToString, @EqualsAndHashCode, @RequiredArgsConstructer를 자동으로 설정해주는 역할을 한다. 테스트 용도로만 사용하고 실무에서는 잘 사용하지 않는다.

• ex) http://localhost:8080/v1/tutor + x-www-form-urlencoded

@Data
public class Tutor {

	private String name;
	private int age;

}

@Controller
public class ModelAttributeController {

	@ResponseBody
  @PostMapping("/v1/tutor")
  public String requestParamV1(
          @RequestParam String name,
          @RequestParam int age
  ) {
      Tutor tutor = new Tutor();
      tutor.setName(name);
      tutor.setAge(age);

      return "tutor name = " + name + " age = " + age;
  }

}

• @RequestParam 의 Mapping을 사용하게 되면 위와 같은 객체를 생성하는 코드가 포함된다.
  • @ModelAttribute 는 해당 과정을 자동화 한다.
• Postman

POST /v1/tutor
content-type: application/x-www-form-urlencoded

name=wonuk&age=100

@ModelAttribute 적용

• ex) http://localhost:8080/v2/tutor+ x-www-form-urlencoded

@ResponseBody
@PostMapping("/v2/tutor")
public String modelAttributeV2(
				@ModelAttribute Tutor tutor													
) {
		
	String name = tutor.getName();
	int age = tutor.getAge();

	return "tutor name = " + name + " age = " + age;
}

• Postman

POST /v2/tutor
content-type: application/x-www-form-urlencoded

name=wonuk&age=100

• @ModelAttirubte 동작 순서
  1. 파라미터에 @ModelAttribute가 있으면 파라미터인 Tutor 객체를 생성한다.
  2. 요청 파라미터 이름으로 객체 필드의 Setter를 호출해서 바인딩한다.
     1. 파라미터 이름이 name 이면 setName(value); 메서드를 호출한다.
     2. 파라미터 이름과 필드 이름이 반드시 같아야 한다!
• @Data의 Setter가 없다면?

@Getter
public class Tutor {

	private String name;
	private int age;

}

• 객체 필드에 값이 set되지 않는다.

• 파라미터의 타입이 다른 경우
  • 만약 요청 파라미터 age 에 int가 아닌 String 이 전달된다면?
  ex) http://localhost:8080/v2/tutor+ x-www-form-urlencoded

POST /v2/tutor
content-type: application/x-www-form-urlencoded

name=wonuk&age=nbcamp

• BindException 발생
• 이런 경우 때문에 **Validation(검증)**이 필요하다.

@ModelAttirubte 생략

• @ModelAttribute와 지난 시간에 배운 @RequestParam은 모두 생략이 가능하다.

ex) http://localhost:8080/v3/tutor+ x-www-form-urlencoded

POST /v3/tutor
content-type: application/x-www-form-urlencoded

name=wonuk&age=100

@ResponseBody
@PostMapping("/v3/tutor")
public String modelAttributeV3(Tutor tutor) {

	String name = tutor.getName();
	int age = tutor.getAge();

	return "tutor name = " + name + " age = " + age;
}

• Spring에서는 @RequestParam이나 @ModelAttribute가 생략되면
  • String, int, Integer 와 같은 기본 타입은 @RequestParam과 Mapping한다. V4

@ResponseBody
@PostMapping("/v4/tutor")
public String requestParamV2(
        String name,
        int age
) {
    return "tutor name = " + name + " age = " + age;
}

• 나머지 경우들(객체)은 모두 @ModelAttribute 와 Mapping한다. V3

@RequestParam vs @ModelAttribute 차이

주요 차이점

사용 목적에 따른 선택

@RequestParam

• 요청 데이터가 단순한 Key-Value 쌍이고, 각각 개별적으로 처리할 경우.
• 쿼리 파라미터나 단일 폼 데이터 값에 적합.

@ModelAttribute

• 요청 데이터가 객체로 표현 가능한 경우.
• 복잡한 폼 데이터(여러 필드가 있는 객체)를 처리하거나, 뷰와 데이터를 쉽게 연동할 때 유리.

요약

결론

• **@RequestParam**은 단일 데이터(Key-Value) 처리에 적합하며, 간단한 요청에 사용됩니다.
• **@ModelAttribute**는 폼 데이터나 요청 데이터를 객체 형태로 처리하거나, 뷰와 연동된 데이터를 전달할 때 유용합니다.
• @RequestParam, @ModelAttribute는 GET + Query Parameter와, POST HTML Form Data를 바인딩하는 방법이다.

HTTP Message Body (요청)

📌 HTTP 요청(Request) 또는 응답(Response)에서 실제 데이터를 담는 부분입니다.

• 주로 클라이언트와 서버 간에 전송되는 JSON, XML, HTML, 바이너리 파일, 텍스트 등 다양한 콘텐츠를 포함합니다.

특징

• 이제부터 배울 내용은 HTTP Message Body에 직접적으로 Data가 전달되는 경우이다.
  • Request Body의 Data를 바인딩하는 방법이다.
• REST API에서 주로 사용하는 방식이다.
• HTTP Method POST, PUT, PATCH에서 주로 사용한다.
  • GET은 Request Body가 존재할 수는 있지만 권장하지 않는다.
• JSON, XML, TEXT 등을 데이터 형식으로 사용한다.

• Server에서 Request로 전달받은 Data를 처리하기 위해서 바인딩 해야 한다.

ex) JSON → Object

TEXT

📌  HTTP Request Body에 Data가 전송되는 경우 HttpMessageConverter를 통해 바인딩된다.

• 현대에는 Restful API를 주로 사용하고 있어서 대부분의 경우 JSON 형식으로 통신한다.

HttpServletRequest 예시

• request.getInputStream();

@Slf4j
@Controller
public class RequestBodyStringController {
	
	@PostMapping("/v1/request-body-text")
  public void requestBodyTextV1(
          HttpServletRequest request,
          HttpServletResponse response
  ) throws IOException {

      ServletInputStream inputStream = request.getInputStream();
      String bodyText = StreamUtils.copyToString(inputStream, StandardCharsets.UTF_8);
      
      response.getWriter().write("response = " + bodyText);

  }

}

• Request → Body → raw → Text