[스프링 3팀] 5장~6.5장. API 작성과 데이터베이스 연동

 

5장: API를 작성하는 다양한 방법

이번 장에서는 HTTP 메서드를 활용해 애플리케이션 개발에 필요한 내용을 소개합니다. 데이터베이스를 설치하지 않고도 외부 요청을 받아 응답하는 기능을 컨트롤러에서 어떻게 구현하는지 살펴봅니다.

 

5.1 프로젝트 설정

프로젝트를 설정하기 위해 groupId는 com.springboot, artifactId는 api로 생성합니다. 디렉토리 구조는 아래와 같이 설정합니다.

controller 패키지와 GetController 클래스 생성

 

5.2 GET API 만들기

GET API는 웹 애플리케이션 서버에서 값을 가져올 때 사용됩니다. 이번 장에서는 다양한 GET API 구현 방법을 다룹니다.

 

5.2.1 @RequestMapping으로 구현하기

@RequestMapping은 메서드에 요청 URL과 HTTP 메서드(GET, POST 등)를 매핑합니다.

@RestController
@RequestMapping("/api/v1/get-api")
public class GetController {

    // http://localhost:8080/api/v1/get-api/hello
    @RequestMapping(value = "/hello", method = RequestMethod.GET)
    public String getHello() {
        return "Hello World";
    }
}

1. 클래스 수준의 @RequestMapping은 공통 URL 설정
2. method 속성을 사용해 GET 요청만 받도록 설정

Talend API Tester에서 /hello 호출

 

5.2.2 매개변수 없는 GET 메서드

매개변수를 받지 않는 간단한 GET API 구현:

// http://localhost:8080/api/v1/get-api/name
@GetMapping(value = "/name")
public String getName() {
    return "Flature";
}

 

요청을 보내면 응답 값 "Flature"를 반환합니다.

/name 호출 및 결과 화면

 

5.2.3 @PathVariable을 활용한 GET 메서드

URL 경로에서 값을 추출하여 매개변수로 받습니다.

// http://localhost:8080/api/v1/get-api/variable1/{value}
@GetMapping(value = "/variable1/{variable}")
public String getVariable1(@PathVariable String variable) {
    return variable;
}

• URL {} 안에 입력된 값을 추출
• 주로 간단한 데이터 전달에 사용

/variable1/{value} 호출 화면

 

변수 이름 매핑이 다른 경우

// http://localhost:8080/api/v1/get-api/variable2/{value}
@GetMapping(value = "/variable2/{variable}")
public String getVariable2(@PathVariable(value = "variable") String var) {
    return var;
}

 

@PathVariable의 value 속성을 활용해 변수명 매핑

/variable2/{value} 호출 결과

 

5.2.4 @RequestParam을 활용한 GET 메서드

쿼리스트링(Query String)으로 데이터를 전달받습니다.

// http://localhost:8080/api/v1/get-api/request1?name=value1&email=value2&organization=value3
@GetMapping(value = "/request1")
public String getRequestParam1(
    @RequestParam String name,
    @RequestParam String email,
    @RequestParam String organization) {
    return name + " " + email + " " + organization;
}

• ? 뒤의 쿼리스트링을 매핑
• 매개변수 이름과 동일해야 자동 매핑 가능

/request1 호출 화면

 

Map을 활용한 동적 매개변수 처리

쿼리스트링의 키-값 쌍이 유동적인 경우 Map을 활용합니다.

// http://localhost:8080/api/v1/get-api/request2?key1=value1&key2=value2
@GetMapping(value = "/request2")
public String getRequestParam2(@RequestParam Map<String, String> param) {
    StringBuilder sb = new StringBuilder();

    param.forEach((key, value) -> {
        sb.append(key).append(" : ").append(value).append("\n");
    });

    return sb.toString();
}

/request2 호출 화면

 

Tip: URI와 URL의 차이

• URL은 웹 주소를 의미하며, 특정 리소스의 위치를 나타냅니다.
• URI는 URL을 포함하는 상위 개념으로, 리소스를 식별하기 위한 경로를 나타냅니다.

 

5.2.5 DTO 객체를 활용한 GET 메서드 구현

DTO란?

DTO(Data Transfer Object)는 레이어 간 데이터 교환을 위해 사용되는 객체입니다. 주로 데이터 전달을 위해 설계되며, 비즈니스 로직은 포함하지 않습니다. DTO는 데이터 교환 외의 용도로는 사용되지 않기 때문에 로직이 포함되지 않는다는 특징이 있습니다.

 

Tip: DTO와 VO의 차이

• VO(Value Object): 읽기 전용(Read-Only) 객체로 설계되며, 데이터 신뢰성을 유지
• DTO: 계층 간 데이터 교환을 목적으로 설계. 외부와 데이터를 주고받는 데 사용

DTO와 VO를 명확히 구분하지 않고 사용하는 경우도 있지만, 개념의 혼동을 줄이기 위해 각각의 목적에 맞게 사용하는 것이 중요합니다.

 

DTO 클래스 생성

DTO 클래스 구조와 패키지 구성

public class MemberDto {
    private String name;
    private String email;
    private String organization;

    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;
    }

    public String getOrganization() {
        return organization;
    }

    public void setOrganization(String organization) {
        this.organization = organization;
    }

    @Override
    public String toString() {
        return "MemberDto{" +
               "name='" + name + '\'' +
               ", email='" + email + '\'' +
               ", organization='" + organization + '\'' +
               '}';
    }
}

 

DTO 활용한 GET 메서드 구현

DTO를 활용해 클라이언트에서 전달받은 쿼리스트링 데이터를 매핑하는 방법은 다음과 같습니다.

 

DTO 객체를 활용한 GET 메서드 구현

@GetMapping(value = "/request3")
public String getRequestParam3(MemberDto memberDto) {
    return memberDto.toString();
}

 

DTO 객체의 toString() 메서드를 통해 데이터가 반환됩니다.

DTO를 활용한 GET 메서드 호출 결과

 

5.3 POST API 만들기

POST API란?

POST API는 클라이언트에서 서버로 데이터를 전달하여 저장소에 추가하거나 저장하는 데 사용됩니다. GET API와 달리 데이터를 URL이 아닌 HTTP Body에 담아 전달합니다.

 

POST API 구현

1. 컨트롤러 생성 및 URL 매핑

컨트롤러 클래스에서 URL 설정

@RestController
@RequestMapping("/api/v1/post-api")
public class PostController {
}

 

2. POST 메서드 구현

(1) @RequestMapping을 사용한 구현

@RequestMapping(value = "/domain", method = RequestMethod.POST)
public String postExample() {
    return "Hello Post API";
}

 

(2) @RequestBody와 Map을 활용한 POST 메서드 구현

Talend API Tester에서 POST 요청 작성

@PostMapping(value = "/member")
public String postMember(@RequestBody Map<String, Object> postData) {
    StringBuilder sb = new StringBuilder();

    postData.entrySet().forEach(map -> {
        sb.append(map.getKey()).append(" : ").append(map.getValue()).append("\n");
    });

    return sb.toString();
}

 

(3) DTO 객체를 활용한 POST 메서드 구현

@PostMapping(value = "/member2")
public String postMemberDto(@RequestBody MemberDto memberDto) {
    return memberDto.toString();
}

 

5.4 PUT API 만들기

PUT API는 서버에 있는 리소스를 업데이트하거나 수정할 때 사용됩니다. POST API와는 목적이 다르며, 기존 리소스의 값을 변경하는 데 주로 활용됩니다. PUT API를 구현하는 방법은 POST API와 거의 동일하지만, 주로 업데이트 작업에 사용된다는 점에서 차이가 있습니다.

5.4.1 @RequestBody를 활용한 PUT 메서드 구현

PutController 클래스

@RestController
@RequestMapping("/api/v1/put-api")
public class PutController {
}

 

이 클래스는 PUT 요청을 처리하기 위해 설정된 컨트롤러입니다. @RestController와 @RequestMapping 어노테이션을 활용해 URL과 메서드 매핑을 설정합니다.

 

@RequestBody와 Map을 활용한 PUT 메서드 구현

@PutMapping(value = "/member")
public String postMember(@RequestBody Map<String, Object> putData) {
    StringBuilder sb = new StringBuilder();

    putData.entrySet().forEach(map -> {
        sb.append(map.getKey() + " : " + map.getValue() + "\n");
    });

    return sb.toString();
}

 

이 코드는 클라이언트로부터 HTTP Body 데이터를 받아 Map 형태로 처리합니다. Map 객체를 사용하면 요청으로 전달된 값들을 유연하게 처리할 수 있습니다. StringBuilder를 활용해 각 key-value를 조합한 결과를 반환합니다.

 

DTO 객체를 활용한 PUT 메서드 구현

DTO 객체를 활용한 PUT 메서드

@PutMapping(value = "/member1")
public String postMemberDto1(@RequestBody MemberDto memberDto) {
    return memberDto.toString();
}

 

postMemberDto1: 요청 데이터를 MemberDto 객체로 매핑하고 toString() 결과를 반환

Talend API Tester에서 PUT 요청 작성

응답 결과

---

@PutMapping(value = "/member2")
public MemberDto postMemberDto2(@RequestBody MemberDto memberDto) {
    return memberDto;
}

 

postMemberDto2: 요청 데이터를 MemberDto로 매핑한 후 그대로 반환

PUT 요청 작성

응답 결과

 

5.4.2 ResponseEntity를 활용한 PUT 메서드 구현

ResponseEntity 클래스는 HTTP 응답을 구성할 때 유용합니다. 이 클래스는 HTTP 상태 코드와 헤더를 설정할 수 있어, PUT API 구현 시 더 정교한 응답 구성이 가능합니다.

 

ResponseEntity 클래스 구조

public class ResponseEntity<T> extends HttpEntity<T> {
    private final Object status;
    ...
}

 

이 클래스는 HttpEntity를 상속하며, Body와 Headers를 가집니다. 이를 통해 서버에서 클라이언트로 전달할 응답 메시지를 더 세밀하게 구성할 수 있습니다.

 

ResponseEntity를 활용한 PUT 메서드

@PutMapping(value = "/member3")
public ResponseEntity<MemberDto> postMemberDto3(@RequestBody MemberDto memberDto) {
    return ResponseEntity
            .status(HttpStatus.ACCEPTED)
            .body(memberDto);
}

 

위 메서드는 다음과 같은 방식으로 작동합니다:

• HTTP 상태 코드를 HttpStatus.ACCEPTED로 설정
• 요청 Body 데이터를 그대로 응답 Body로 전달

ResponseEntity를 적용한 메서드의 응답 내용

 

5.5 DELETE API 만들기

DELETE API는 데이터베이스에 저장된 특정 데이터를 삭제하기 위해 사용됩니다. 클라이언트는 DELETE 요청을 통해 서버에서 리소스를 삭제하도록 요청할 수 있습니다. DELETE 메서드는 URI의 값을 받아 서버에서 삭제 작업을 수행합니다.

 

DeleteController 클래스

@RestController
@RequestMapping("/api/v1/delete-api")
public class DeleteController {
}

 

5.5.1 @PathVariable과 @RequestParam을 활용한 DELETE 메서드 구현

@PathVariable: URI 경로에 포함된 값을 매개변수로 받아 로직을 처리할 수 있습니다.

// http://localhost:8080/api/v1/delete-api/{value}
@DeleteMapping(value = "/{variable}")
public String DeleteVariable(@PathVariable String variable) {
    return variable;
}

 

@RequestParam: 쿼리 스트링의 값을 매개변수로 받아 로직을 처리할 수 있습니다.

// http://localhost:8080/api/v1/delete-api/request1?email=value
@DeleteMapping(value = "/request1")
public String getRequestParam1(@RequestParam String email) {
    return "e-mail : " + email;
}

 

5.6 REST API 명세를 문서화하는 방법 - Swagger

API 개발 시 명세 문서를 작성하면 요청과 응답에 대한 정보를 체계적으로 정리할 수 있습니다. 하지만 명세 문서를 수동으로 작성하면 시간이 오래 걸릴 뿐만 아니라 오류 가능성도 존재합니다. 이를 해결하기 위해 Swagger를 활용할 수 있습니다.

 

Swagger 의존성 추가

<dependencies>
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger2</artifactId>
        <version>2.9.2</version>
    </dependency>
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger-ui</artifactId>
        <version>2.9.2</version>
    </dependency>
</dependencies>

 

Swagger 설정 클래스 작성

SwaggerConfiguration 클래스는 설정(Configuration)에 관련된 코드를 작성합니다.

@Configuration
@EnableSwagger2
public class SwaggerConfiguration {

    @Bean
    public Docket api() {
        return new Docket(DocumentationType.SWAGGER_2)
                .apiInfo(apiInfo())
                .select()
                .apis(RequestHandlerSelectors.basePackage("com.springboot.api"))
                .paths(PathSelectors.any())
                .build();
    }

    private ApiInfo apiInfo() {
        return new ApiInfoBuilder()
                .title("Spring Boot Open API Test with Swagger")
                .description("설명 부분")
                .version("1.0.0")
                .build();
    }
}

 

Swagger 실행 화면

Swagger 설정을 완료한 후 애플리케이션을 실행하면, 브라우저를 통해 Swagger UI에 접근할 수 있습니다. http://localhost:8080/swagger-ui.html에서 Swagger 페이지를 확인할 수 있습니다.

Swagger UI 실행 화면

 

Swagger 사용법 확장

Swagger를 더욱 활용하기 위해 작성한 API 중 @RequestParam을 사용하는 GET 메서드의 명세를 작성합니다. GetController에 작성된 메서드를 기반으로 명세를 추가해 봅니다.

기존 코드에 Swagger 명세 추가

@ApiOperation(value = "GET 메서드 예제", notes = "@RequestParam을 활용한 GET Method")
@GetMapping(value = "/request1")
public String getRequestParam1(
    @ApiParam(value = "이름", required = true) @RequestParam String name,
    @ApiParam(value = "이메일", required = true) @RequestParam String email,
    @ApiParam(value = "회사", required = true) @RequestParam String organization) {
    return name + " " + email + " " + organization;
}

 

GET 메서드 내 Swagger 관련 주석 추가

Swagger를 사용하기 위해 아래와 같은 어노테이션을 적용합니다:

1. @ApiOperation: API의 설명 및 목적을 작성하기 위한 어노테이션입니다.
2. @ApiParam: 매개변수에 대한 설명을 작성하기 위한 어노테이션으로, DTO 클래스나 내부 매개변수에도 정의 가능합니다.

 

해당 명세를 작성한 후 Swagger 페이지에서 API 명세 확인

작성된 Swagger 명세를 기반으로 API의 세부 내용을 Swagger 페이지에서 확인할 수 있습니다.

Swagger 페이지에서 확인한 API 명세

 

Swagger API 통신 테스트

Swagger에서는 단순히 API 명세만 제공하는 것이 아니라 직접 통신 테스트도 수행할 수 있습니다.

 

Swagger 페이지 상에서의 테스트 과정

1. 각 항목에 값을 입력합니다. (예: email, name, organization)
2. [Execute] 버튼을 클릭하면 요청이 전송되며, 결과값을 확인할 수 있습니다.

Swagger를 통해 실제 요청을 전송한 후 입력값을 기반으로 작성된 Request URL 및 Server Response가 표시됩니다.

요청에 대한 응답값(Response Body) 및 Header 정보를 확인할 수 있습니다.

 

Talend API Tester와 Swagger의 차이점

앞선 단계에서는 Talend API Tester를 사용하여 API 요청 및 테스트를 진행했지만, Swagger를 통해 동일한 기능을 수행할 수 있습니다. Swagger는 UI를 제공하며, 별도 툴 없이도 API 문서화 및 테스트가 가능합니다.

 

5.7 로깅 라이브러리 - Logback

로깅은 애플리케이션 실행 중 발생하는 시스템 상태와 정보를 기록하는 작업입니다. 로그는 디버깅 시 문제를 해결하거나 원인을 분석하는 데 매우 유용합니다. Spring Boot는 Logback 프레임워크를 기본적으로 사용합니다.

Logback의 특징

• TRACE, DEBUG, INFO, WARN, ERROR 레벨로 로그를 설정 가능
• ERROR: 애플리케이션 작동이 불가능한 경우
• WARN: 경고
• INFO: 상태 변경 등의 정보 전달
• DEBUG: 개발 디버깅 정보
• TRACE: 세부 메시지

Logback 설정 파일에서 출력 형식, 로그 레벨 등을 정의할 수 있습니다.

 

5.7.1 Logback 설정

Logback을 설정하기 위해 설정 파일을 작성합니다. 일반적으로 classpath에 있는 설정 파일을 자동으로 참조하도록 설정됩니다. 스프링 부트에서는 보통 logback-spring.xml 파일을 사용하며, 설정 파일의 추가는 다음 사진과 같습니다.

Logback 설정 파일 추가

Logback 설정 파일의 예시

Logback 설정 파일은 XML 형식으로 작성됩니다. 아래는 설정 파일의 예시입니다:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property name="LOG_PATH" value="./logs"/>
    
    <!-- Appenders -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5level] [%thread] %logger %msg%n</pattern>
        </encoder>
    </appender>

    <appender name="INFO_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
        <file>${LOG_PATH}/info.log</file>
        <append>true</append>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/info_%d{yyyy-MM-dd}.gz</fileNamePattern>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5level] [%thread] %logger %msg%n</pattern>
        </encoder>
    </appender>

    <!-- Root Logger -->
    <root level="INFO">
        <appender-ref ref="console"/>
        <appender-ref ref="INFO_LOG"/>
    </root>
</configuration>

 

Logback 설정 파일의 주요 영역

설정 파일의 주요 영역은 다음과 같이 구분됩니다:

1. Property 영역 (3번 줄): 로그 경로 등을 정의
2. Appender 영역 (6~28번 줄): 로그를 출력하는 형태와 방법을 정의
3. Encoder 영역 (10~12, 25~27번 줄): 로그의 표현 형식을 설정
4. Pattern 영역 (11, 26번 줄): 로그 메시지의 출력 패턴을 설정
5. Root Logger 영역 (32~35번 줄): 기본적으로 사용되는 로그의 레벨과 출력 Appender를 지정

 

Appender 영역

Appender는 로그의 출력 방식을 설정하는 영역으로, 다양한 구현체가 있습니다:

Logback의 Appender 구조

• ConsoleAppender: 콘솔에 출력
• FileAppender: 파일에 출력
• RollingFileAppender: 여러 파일에 순환하며 저장
• SMTPAppender: 메일로 로그 전송
• DBAppender: 데이터베이스에 로그 저장

예제에서 사용된 Appender는 다음과 같습니다:

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>INFO</level>
    </filter>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5level] [%thread] %logger %msg%n</pattern>
    </encoder>
</appender>

<appender name="INFO_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <level>INFO</level>
    </filter>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5level] [%thread] %logger %msg%n</pattern>
    </encoder>
</appender>

 

Pattern 영역

Pattern은 로그의 메시지 출력 형식을 정의합니다. 자주 사용되는 패턴은 다음과 같습니다:

패턴	의미
%Logger{length}	로거의 이름
%-5lebel	로그 레벨. -5는 출력 고정폭의 값
%msg(%message)	로그 메시지
%d	로그 기록 시간
%p	로깅 레벨
%F	로깅이 발생한 애플리케이션 파일명
%M	로깅이 발생한 메서드 이름
%I	로깅이 발생한 호출지의 정보
%thread	현재 스레드명
%t	로깅이 발생한 스레드명
%c	로깅이 발생한 카테고리
%C	로깅이 발생한 클래스명
%m	로그 메시지
%n	줄바꿈
%r	애플리케이션이 실행 후 로깅이 발생한 시점까지의 시간
%L	로깅이 발생한 호출 지점의 라인 수

 

예제 패턴:

%pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%5level] [%thread] %logger %msg%n</pattern>

 

Logback Root 영역 및 Logger 설정

Root 영역

Root 영역은 기본 로그 레벨과 Appender를 설정합니다. 모든 로그의 기본값으로 사용되며, 별도 설정이 없을 경우 Root 설정을 따릅니다.

<root level="INFO">
    <appender-ref ref="console"/>
    <appender-ref ref="INFO_LOG"/>
</root>

• 기본 로그 레벨: INFO
• 로그 출력: console과 INFO_LOG Appender 사용

Logger 영역

Logger 영역은 특정 패키지나 클래스의 별도 로그 설정을 정의합니다.

<logger name="com.springboot.api.controller" level="DEBUG" additivity="false">
    <appender-ref ref="console"/>
    <appender-ref ref="INFO_LOG"/>
</logger>

• name: com.springboot.api.controller에 설정 적용
• level: 로그 레벨을 DEBUG로 지정
• additivity: false로 상위 설정 포함하지 않음
• appender-ref: console과 INFO_LOG에 로그 출력

 

5.7.2 Logback 적용하기

Logger 선언

GetController 클래스에서 Logger 객체를 정의하여 사용합니다.

@RestController
@RequestMapping("/api/v1/get-api")
public class GetController {
    
    private final Logger LOGGER = LoggerFactory.getLogger(GetController.class);

    // (후략)
}

 

로그 출력 코드

API 호출 시 로그를 남기도록 설정했습니다.

예제 5.27 로그 출력 코드
// http://localhost:8080/api/v1/get-api/hello
@RequestMapping(value = "/hello", method = RequestMethod.GET)
public String getHello() {
    LOGGER.info("getHello 메서드가 호출되었습니다.");
    return "Hello World";
}

// http://localhost:8080/api/v1/get-api/name
@GetMapping(value = "/name")
public String getName() {
    LOGGER.info("getName 메서드가 호출되었습니다.");
    return "Flature";
}

 

Swagger 테스트

Swagger에서 'hello'와 'name' API를 테스트한 후, 로그를 확인합니다.

Swagger 테스트 화면

콘솔에 출력된 로그

 

변수 로그 출력

PathVariable로 전달받은 변수값을 Logger로 출력합니다.

// http://localhost:8080/api/v1/get-api/variable1/{String 값}
@GetMapping(value = "/variable1/{variable}")
public String getVariable1(@PathVariable String variable) {
    LOGGER.info("@PathVariable 값: {}", variable);
    return variable;
}

 

테스트 결과

Swagger에서 'Wikibooks' 입력 후, 로그에 출력된 값을 확인합니다.

로그에 변수의 값을 출력

 

6. 데이터베이스 연동

애플리케이션은 데이터를 주고받는 것이 주요 목적입니다. 여기서는 MariaDB를 설치하고 애플리케이션과 연동하는 방법을 다룹니다.

 

6.1 마리아DB 설치

MariaDB 다운로드 페이지에서 설치 파일을 받습니다.

• MariaDB Server Version: 10.6.5
• Operating System: Windows
• Architecture: x86_64
• Package Type: MSI Package

버전이 다르면 [Display older releases]를 체크해 10.6.5로 맞춥니다. 파일 다운로드 후 설치 프로그램을 실행합니다.

 

설치 단계

1. 설치 시작
   설치를 실행하면 Setup Wizard가 나타납니다. Next를 눌러 진행합니다.
2. 루트 패스워드 설정
   root 계정의 비밀번호를 설정합니다. [Use UTF8 as default server's character set]를 체크해 UTF-8을 기본 인코딩으로 설정합니다.
3. 서버 이름 및 포트 설정
   서버 이름과 포트를 설정합니다.
   • 기본 포트는 3306이며, 기존 설치가 있을 경우 3307로 자동 변경됩니다.
4. 기본 설정 유지
   모든 기본값을 유지하고 Next를 눌러 설치를 완료합니다. HeidiSQL도 함께 설치됩니다.

 

HeidiSQL로 데이터베이스 접속

HeidiSQL은 데이터베이스 접속과 관리를 위한 GUI 도구입니다. 실행 후 초기 화면이 나타납니다.

1. 세션 생성
   아래 정보를 입력 후 [열기]를 클릭합니다.
   • 세션 이름: springboot
   • 호스트명/IP: 127.0.0.1
   • 사용자: root
   • 암호: 설치 시 설정한 비밀번호
   • 포트: 3306 (혹은 설치 시 설정된 값)
   정상적으로 연결되면 화면이 표시됩니다.
2. 데이터베이스 생성
   Query Editor에 다음 명령어를 입력하고 실행 버튼(▶) 또는 F9 키를 눌러 데이터베이스를 생성합니다.

CREATE DATABASE springboot;

 

생성이 완료되면 springboot 데이터베이스가 추가됩니다.

 

6.2 ORM (Object Relational Mapping)

• 정의
  ORM은 객체지향 언어에서 정의한 객체와 관계형 데이터베이스 테이블을 자동으로 매핑하는 방식입니다. 클래스는 데이터베이스의 테이블을 매핑하기 위해 만든 것이 아니므로, ORM은 이 간극을 해결하는 역할을 합니다.
• ORM의 역할
  스프링부트 애플리케이션의 클래스와 데이터베이스의 테이블을 연결하며, 이를 통해 개발자는 SQL 없이 메서드로 데이터를 조작할 수 있습니다.

ORM의 역할

• 장점
  1. 객체지향적 데이터베이스 조작 가능
     • 코드 가독성과 생산성 향상
  2. 재사용성 및 유지보수 용이
     • 클래스 단위로 객체를 나누어 관리
  3. 데이터베이스에 대한 종속성 감소
     • 데이터베이스 교체 시 리스크가 적음
• 단점
  • 복잡한 서비스에서 성능 저하 가능
  • 직접 SQL 작성이 어려움

 

6.3 JPA (Java Persistence API)

• 정의
  JPA는 자바 ORM 기술의 표준 명세로, ORM을 확장한 개념입니다. JPA는 SQL 생성과 객체 매핑을 자동화하여 개발자가 효율적으로 데이터베이스와 상호작용할 수 있도록 지원합니다.

JPA의 역할

• JPA 구현체
  • Hibernate, EclipseLink, DataNucleus 등
  • Hibernate가 가장 널리 사용됩니다.

JPA 구현체의 구조

 

6.4 Hibernate

• 정의
  Hibernate는 JPA 구현체 중 하나로, 데이터베이스 작업을 단순화합니다. 이 책에서는 Spring Data JPA와 함께 Hibernate를 사용해 데이터베이스와 연동합니다.

Hibernate와 Spring Data JPA의 관계

 

6.5 영속성 컨텍스트 (Persistence Context)

• 정의
  영속성 컨텍스트는 애플리케이션 객체와 데이터베이스 간 매핑을 관리하는 공간입니다. 엔티티 객체가 영속성 컨텍스트에 등록되면, 해당 객체는 데이터베이스 상태와 동기화됩니다.

영속성 컨텍스트의 구조

 

6.5.1 엔티티 매니저

• 엔티티 매니저는 엔티티를 관리하는 객체입니다.
• JPA 설정 파일 persistence.xml에서 매니저 팩토리를 정의합니다.

persistence.xml

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
    http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
    version="2.1">
  <persistence-unit name="entity_manager_factory" transaction-type="RESOURCE_LOCAL">
    <properties>
      <property name="javax.persistence.jdbc.driver" value="org.mariadb.jdbc.Driver" />
      <property name="javax.persistence.jdbc.user" value="root" />
      <property name="javax.persistence.jdbc.password" value="password" />
      <property name="javax.persistence.jdbc.url" value="jdbc:mariadb://localhost:3306/springboot" />
      <property name="hibernate.dialect" value="org.hibernate.dialect.MariaDB103Dialect" />
      <property name="hibernate.show_sql" value="true" />
      <property name="hibernate.format_sql" value="true" />
    </properties>
  </persistence-unit>
</persistence>

 

6.5.2 엔티티의 생명주기

엔티티 객체는 영속성 컨텍스트에서 4가지 상태로 나뉩니다.

1. 비영속 (New)
   • 컨텍스트에 등록되지 않은 상태
2. 영속 (Managed)
   • 컨텍스트에 의해 관리되는 상태
3. 준영속 (Detached)
   • 컨텍스트와 분리된 상태
4. 삭제 (Removed)
   • 데이터베이스 삭제 요청 상태

---

 

QUIZ

 

1. GET API는 웹 애플리케이션 서버에서 값을 가져올 때 사용되며, 요청을 처리하기 위해 _________ 어노테이션을 사용한다.
2. DTO는 계층 간 데이터 교환을 위해 사용되는 객체로, _________은 포함되지 않는다.
3. POST API는 데이터를 _________에 담아 전달하며, 클라이언트에서 서버로 데이터를 저장하기 위해 사용된다.
4. PUT API는 기존 리소스를 _________하거나 _________하는 데 사용된다.
5. DELETE API에서 URI 경로에 포함된 값을 매개변수로 받기 위해 _________ 어노테이션을 사용한다.
6. JPA는 자바 ORM 기술의 표준 명세로, SQL 생성과 _________을 자동화하여 개발자가 데이터베이스와 효율적으로 상호작용할 수 있도록 지원한다.
7. 영속성 컨텍스트는 애플리케이션 객체와 데이터베이스 간 매핑을 관리하는 공간으로, 엔티티 객체가 _________에 등록되면 데이터베이스 상태와 동기화된다.

 

PROGRAMMING QUIZ

1. @RequestParam을 활용하여 이름, 이메일, 조직 정보를 전달받고 출력하는 GET 메서드 작성하기
   다음과 같은 요청을 처리하는 코드를 작성하세요.
   예: http://localhost:8080/api/v1/get-api/request?name=John&email=john@example.com&organization=TechCorp
2. DTO 객체를 활용한 POST 메서드 작성하기
   클라이언트에서 전달받은 데이터를 MemberDto 객체에 매핑하고 반환하는 POST 메서드를 작성하세요.

 

---

정답

QUIZ 정답 :
@GetMapping, 비즈니스 로직, HTTP Body, (업데이트, 수정), @PathVariable, 객체 매핑, 영속성 컨텍스트


PROGRAMING QUIZ 정답:

1번

@GetMapping(value = "/request")
public String getRequestParam(
    @RequestParam String name,
    @RequestParam String email,
    @RequestParam String organization) {
    return "Name: " + name + ", Email: " + email + ", Organization: " + organization;
}​

2번:

@PostMapping(value = "/member")
public String postMemberDto(@RequestBody MemberDto memberDto) {
    return "Received Member Info: " + memberDto.toString();
}​

---

[출처] 장정우, ｢스프링부트 핵심 가이드｣ 5장 ~ 6.5.2장

 

Corner Spring 3

ⓒ Hetbahn