서블릿 보충자료
스프링 이니셜라이저
1. Project
설정 항목: Gradle - Groovy, Gradle - Kotlin, Maven 설명: 프로젝트에서 사용할 빌드 도구를 선택합니다.
Gradle: Groovy DSL 또는 Kotlin DSL을 사용하는 현대적인 빌드 도구입니다. Gradle은 빌드 속도와 유연성에서 장점을 가지며, 특히 대규모 프로젝트에서 유용합니다.
Maven: XML 기반의 전통적인 빌드 도구입니다. 구조가 단순하고 표준화되어 있지만 유연성은 상대적으로 낮습니다.
Gradle은 초기에 Groovy DSL을 사용했으나, 현재는 Kotlin DSL을 점차 채택하는 추세입니다.
빌드(Build)란?
빌드는 소스 코드를 실행 가능한 프로그램(애플리케이션)으로 변환하는 과정을 의미합니다. 이 과정에는 코드의 컴파일, 의존성 관리, 테스트 실행, 패키징 등이 포함됩니다.
간단히 말해: 개발자가 작성한 코드를 컴퓨터가 이해하고 실행할 수 있는 형태로 만드는 작업입니다.
2. Language
설정 항목: Java, Kotlin, Groovy 설명: 프로젝트에서 사용할 프로그래밍 언어를 선택합니다.
Java: JVM 기반의 가장 널리 사용되는 언어로, 안정성과 호환성이 뛰어납니다.
Kotlin: 현대적인 문법과 간결성을 제공하는 JVM 언어로, 생산성이 높아지는 장점이 있습니다. Spring Boot에서도 적극 지원합니다.
Groovy: 동적 언어로, 스크립트 기반 작업에서 유용하지만 현재 주요 개발 언어로는 사용 빈도가 낮아지고 있습니다.
3. Spring Boot
설정 항목: 다양한 Spring Boot 버전 선택 가능 설명: Spring Boot의 버전을 선택합니다.
최신 안정 버전을 선택하는 것이 권장됩니다.
특정 요구사항이 있거나 실험적인 기능을 사용하려는 경우 SNAPSHOT 버전을 선택할 수도 있습니다.
Spring Boot 버전의 의미:
3.4.0
: 정식 릴리스 버전3.4.1 (SNAPSHOT)
: 개발 중인 버전으로, 최신 기능을 테스트할 때 사용합니다.
4. Project Metadata
4.1 Group
설명:
프로젝트를 식별하는 고유한 그룹 이름으로, 보통 역방향 도메인 형식을 따릅니다.
예: com.example
, org.apache
이 그룹은 프로젝트의 소속이나 네임스페이스를 정의하며, 의존성 충돌을 방지하는 데 중요합니다.
4.2 Artifact
설명:
프로젝트 또는 애플리케이션의 이름을 지정합니다. 이 값은 생성되는 프로젝트 폴더와 .jar
파일 이름에 반영됩니다.
예: demo
, my-application
4.3 Name
설명: 프로젝트의 이름입니다. 일반적으로 Artifact와 동일하게 설정하지만, 필요에 따라 다르게 설정할 수도 있습니다.
4.4 Description
설명:
프로젝트를 간략히 설명하는 텍스트입니다. 프로젝트에 대한 메타정보로 사용됩니다.
예: Demo project for Spring Boot
4.5 Package Name
설명:
기본 패키지 이름입니다. 보통 Group + Artifact
를 결합하여 생성됩니다.
예: hello.servlet.demo
이 패키지 이름은 생성되는 클래스 파일들이 위치할 기본 패키지를 정의합니다.
5. Packaging
설정 항목: Jar, War 설명: 애플리케이션을 배포할 형식을 선택합니다.
Jar: 대부분의 Spring Boot 애플리케이션에서 사용하는 기본 형식으로, 독립 실행형 애플리케이션으로 동작합니다.
War: 기존의 웹 서버(Tomcat, Jetty 등)에 배포할 경우 사용합니다. Spring Boot 3.x 이후로는 Jar가 권장됩니다.
6. Java
설정 항목: 17, 21, 23 설명: 프로젝트에서 사용할 Java 버전을 선택합니다. Spring Boot는 최소 Java 17 이상을 요구하며, 최신 기능을 사용하려면 최신 버전을 선택하는 것이 좋습니다.
Java 17: 장기 지원(LTS) 버전으로, 안정성과 호환성이 보장됩니다.
Java 21: 최신 LTS 버전으로 더 많은 기능과 개선 사항을 포함합니다.
Java 23: 최신 비-LTS 버전으로, 최신 기술을 테스트할 때 유용합니다.
7. Dependencies
설명: 프로젝트에서 사용할 Spring Boot 의존성을 선택합니다. 버튼을 클릭하면 다음과 같은 다양한 의존성을 추가할 수 있습니다:
Web: Spring MVC 또는 RESTful API 개발을 위한 의존성.
Security: Spring Security를 통해 인증 및 권한 부여 기능 제공.
JPA: 데이터베이스와의 상호작용을 위한 ORM 라이브러리.
Thymeleaf: HTML 템플릿 엔진.
DevTools: 개발 중 빠른 애플리케이션 재시작 및 라이브 리로드 기능 제공.
필요한 의존성을 선택하면 자동으로 build.gradle
또는 pom.xml
에 추가됩니다.
예제
위 설정을 기반으로 생성된 프로젝트의 Gradle(Groovy DSL) 예제는 다음과 같습니다:
build.gradle
1. plugins
블록
plugins
블록설명:
id 'java'
: Java 플러그인을 적용하여 프로젝트가 Java 애플리케이션임을 선언합니다. 컴파일, 테스트, 패키징 등의 기본 Java 기능을 제공합니다.id 'org.springframework.boot'
: Spring Boot 플러그인을 적용합니다. Spring Boot 애플리케이션 실행 및 패키징 관련 작업(bootRun
,bootJar
)을 추가합니다.id 'io.spring.dependency-management'
: Spring의 의존성 관리 도구를 활성화하여 버전 충돌을 방지하고 Spring Boot BOM(Bill of Materials)을 사용합니다.
2. group
와 version
group
와 version
설명:
group
: 프로젝트의 그룹 ID로, 주로 프로젝트의 네임스페이스를 정의합니다. 일반적으로 역방향 도메인 형식을 사용합니다.version
: 프로젝트 버전을 지정합니다.SNAPSHOT
: 아직 완성되지 않은 개발 버전을 의미합니다.
3. java
블록
java
블록설명:
toolchain
: Java Toolchain을 사용하여 특정 Java 버전에서 코드를 컴파일하고 실행하도록 설정합니다.languageVersion
: 프로젝트에서 사용할 Java의 버전을 지정합니다. 여기서는 Java 17로 설정되었습니다.
4. configurations
블록
configurations
블록설명:
configurations
: Gradle에서 의존성의 범위를 설정합니다.compileOnly
: 컴파일 시에만 필요한 의존성을 지정합니다(런타임에는 포함되지 않음). 여기서는 **annotationProcessor
**를 확장하여 Lombok 어노테이션 처리를 활성화합니다.
5. repositories
블록
repositories
블록설명:
프로젝트에서 사용할 의존성을 다운로드할 **저장소(repository)**를 설정합니다.
mavenCentral()
: Maven Central Repository에서 의존성을 가져옵니다.
6. dependencies
블록
dependencies
블록설명:
의존성을 정의하며, 각 의존성은 특정 작업에서 사용됩니다.
implementation
: 런타임과 컴파일 시 모두 필요한 의존성을 추가합니다.org.springframework.boot:spring-boot-starter-web
: Spring MVC와 REST API 개발을 위한 의존성.
compileOnly
: 컴파일 시에만 필요한 의존성을 추가합니다.org.projectlombok:lombok
: Lombok을 사용하여 Getter/Setter 등을 자동 생성합니다.
annotationProcessor
: Lombok 등의 어노테이션 프로세서를 활성화합니다.org.projectlombok:lombok
: Lombok의 어노테이션 처리 활성화.
testImplementation
: 테스트 코드를 작성하고 실행하는 데 필요한 의존성을 추가합니다.org.springframework.boot:spring-boot-starter-test
: Spring Boot 테스트 라이브러리(JUnit, AssertJ 등 포함).
testRuntimeOnly
: 테스트 시 런타임에만 필요한 의존성을 추가합니다.org.junit.platform:junit-platform-launcher
: JUnit 플랫폼 실행기를 테스트 런타임에서만 포함.
7. tasks.named('test')
tasks.named('test')
설명:
tasks.named('test')
: Gradle의test
작업(단위 테스트 실행)을 설정합니다.useJUnitPlatform()
: JUnit 5(JUnit Platform)를 사용하여 테스트를 실행하도록 지정합니다.
서블릿 컨테이너와 서블릿의 역할
1. 컨테이너란?
컨테이너는 특정 작업이나 목적을 달성하기 위해 필요한 리소스와 환경을 묶어두는 단위입니다. Java 웹 애플리케이션에서 컨테이너는 애플리케이션의 실행, 관리, 배포를 담당하는 환경을 제공합니다.
2. 서블릿 컨테이너란?
서블릿 컨테이너는 다음과 같은 역할을 수행합니다:
서블릿의 생명주기 관리
서블릿 객체의 생성, 초기화, 요청 처리, 소멸 과정을 관리합니다.
HTTP 요청 및 응답 처리
클라이언트의 요청을 처리하고 적절한 응답을 반환합니다.
싱글톤 객체 관리
서블릿 객체는 싱글톤으로 생성되어 재사용됩니다. 동일한 서블릿에 대한 요청은 매번 새로운 객체를 생성하지 않고 기존 객체를 재활용합니다.
3. 서블릿 요청 및 응답 프로세스
서블릿 컨테이너를 통한 요청 및 응답 흐름은 다음과 같이 진행됩니다:
클라이언트가 WAS(Web Application Server)로 요청 전달
브라우저 또는 API 클라이언트가 서버로 HTTP 요청을 보냅니다.
WAS가 서블릿 컨테이너에 요청 전달
서블릿 컨테이너는 요청 URL을 분석하고, 해당 URL에 매핑된 서블릿 객체를 찾아 요청을 전달합니다.
일치하는 서블릿 객체가 요청 처리
HttpServletRequest
객체와HttpServletResponse
객체를 생성합니다.서블릿 객체의
doGet
,doPost
메서드 등이 호출되어 요청을 처리합니다.
응답 반환
요청을 처리한 후,
HttpServletResponse
객체를 통해 클라이언트로 데이터를 반환합니다.반환 데이터는 HTML, JSON, XML 등의 형태가 될 수 있습니다.
프로세스 코드 예제
아래는 서블릿 요청과 응답을 처리하는 간단한 예제입니다.
코드 설명:
HttpServletRequest
객체클라이언트로부터 전송된 요청 데이터를 읽는 데 사용됩니다. 예:
request.getParameter("name")
로 요청 파라미터name
값을 가져옴.
HttpServletResponse
객체클라이언트로 응답 데이터를 보냅니다. 예:
response.getWriter().write()
로 HTML 형식 데이터를 반환.
4. 서블릿 컨테이너 - Tomcat
Tomcat은 가장 널리 사용되는 서블릿 컨테이너 중 하나로, 다음과 같은 역할을 합니다:
서블릿 생명주기 관리.
요청 URL과 서블릿 매핑 처리.
클라이언트의 요청 데이터를 처리하여 적절한 응답 반환.
5. 서블릿의 역할
서블릿은 HTTP 요청과 응답을 처리하기 위한 Java 인터페이스입니다.
서블릿의 주요 역할
HTTP 요청 및 응답 처리
클라이언트 요청을 받아 로직을 처리한 후, HTML, JSON 데이터를 생성하여 응답합니다.
HTTP 메시지 구조 처리
클라이언트와 서버 간 통신은 HTTP 프로토콜을 통해 이루어지며, 이를 서블릿이 처리합니다.
Request와 Response 객체 활용
HttpServletRequest
: 요청 데이터를 포함한 객체.HttpServletResponse
: 응답 데이터를 포함한 객체.
서블릿 동작 과정 요약
클라이언트 -> WAS로 요청 전달.
WAS -> 서블릿 컨테이너에 요청 전달.
서블릿 컨테이너가 요청 URL에 맞는 서블릿 객체 호출.
서블릿에서 요청 처리 후 응답 객체 생성 및 반환.
WAS가 클라이언트에 응답 전달.
추가 코드 예제: JSON 응답 처리
6. 서블릿과 REST API
서블릿은 REST API 개발의 기초가 됩니다.
HTTP 요청 방식: GET, POST, PUT, DELETE 등.
클라이언트 요청에 따라 데이터를 생성하고, 적절히 반환합니다.
결론
서블릿 컨테이너는 서블릿 객체를 관리하며 클라이언트의 HTTP 요청을 처리합니다.
서블릿은 클라이언트 요청과 응답의 핵심적인 역할을 담당하며, Java 웹 애플리케이션 개발의 기본 구성 요소입니다.
Tomcat은 대표적인 서블릿 컨테이너로, Spring Boot와 함께 널리 사용됩니다.
ServletComponentScan 애노테이션 추가
Spring Boot에서 @ServletComponentScan
애노테이션은 서블릿, 필터, 리스너와 같은 컴포넌트를 자동으로 스캔하고 등록하기 위해 사용됩니다. 아래에서 해당 내용과 역할을 자세히 설명합니다.
1. 애노테이션 정의와 역할
**@ServletComponentScan
**은 다음과 같은 작업을 수행합니다:
서블릿:
@WebServlet
애노테이션이 붙은 클래스를 자동으로 등록.필터:
@WebFilter
애노테이션이 붙은 클래스를 자동으로 등록.리스너:
@WebListener
애노테이션이 붙은 클래스를 자동으로 등록.
즉, 이 애노테이션은 Spring Boot가 @WebServlet
, @WebFilter
, @WebListener
로 정의된 서블릿 관련 컴포넌트를 스캔하고 Servlet Container에 등록하도록 합니다.
2. 애노테이션 적용 위치
이 애노테이션은 보통 Spring Boot 애플리케이션의 메인 클래스에 추가됩니다.
예제 코드
src/main/java/boot/start/StartApplication.java
설명:
@ServletComponentScan
:이 애노테이션이 있으면 Spring Boot는 특정 패키지 내에서 서블릿 관련 컴포넌트를 자동으로 스캔하여 등록합니다.
별도의
ServletRegistrationBean
을 통해 서블릿을 수동으로 등록할 필요가 없습니다.
@SpringBootApplication
:Spring Boot의 애플리케이션을 구성하는 기본 애노테이션입니다. 내부적으로 **
@ComponentScan
**과 **@EnableAutoConfiguration
**을 포함합니다.
CDN(Content Delivery Network)
CDN (Content Delivery Network)란?
**CDN (Content Delivery Network)**은 전 세계에 분산된 서버 네트워크를 통해 사용자에게 웹 콘텐츠를 빠르고 안정적으로 제공하기 위한 기술입니다. CDN은 사용자와 가까운 서버에서 콘텐츠를 제공함으로써 로드 시간 단축, 서버 부하 분산, 네트워크 성능 향상 등을 실현합니다.
1. 캐시와 CDN의 관계
캐시(Caching):
자주 사용되는 데이터를 저장해 두고, 필요할 때 빠르게 접근할 수 있도록 하는 기술입니다.
저장소의 위치에 따라 클라이언트 측 캐시(브라우저 캐시), 서버 측 캐시, **중간 캐시(CDN)**로 나뉩니다.
CDN(Content Delivery Network):
전 세계 여러 위치에 분산된 서버에 콘텐츠를 캐시하여 사용자에게 더 가까운 서버에서 데이터를 제공하는 네트워크입니다.
캐시의 대표적인 사용 사례로, 웹 페이지 로딩 속도를 개선하고 대역폭을 줄이는 데 기여합니다.
2. CDN의 동작 원리
기본 흐름
사용자가 브라우저에서 특정 URL로 콘텐츠 요청.
DNS 요청을 통해 CDN이 사용자와 가장 가까운 서버(PoP: Point of Presence)를 선택.
CDN 서버가 캐시된 콘텐츠를 반환(있다면).
캐시된 데이터가 없으면 원본 서버에서 데이터를 가져와 사용자에게 전달.
캐싱의 동작
캐시 히트(Cache Hit):
요청한 데이터가 CDN 캐시에 존재할 경우, 캐시에서 데이터를 즉시 제공.
캐시 미스(Cache Miss):
요청한 데이터가 캐시에 없을 경우, CDN이 원본 서버에서 데이터를 가져와 캐시에 저장한 후 사용자에게 제공.
3. CDN을 사용한 캐시 설명
캐시와 관련된 개념을 CDN으로 설명할 수 있습니다:
정적 콘텐츠 캐싱:
예: 이미지, JavaScript, CSS 파일은 자주 변경되지 않으므로 CDN의 캐시 서버에 저장됩니다.
사용자가 웹사이트를 요청하면, 원본 서버가 아닌 CDN 서버에서 데이터를 제공합니다.
결과: 빠른 로딩 속도와 원본 서버의 부하 감소.
캐시 만료와 갱신:
캐시된 콘텐츠는 TTL(Time to Live) 설정에 따라 일정 시간 동안 유지됩니다.
콘텐츠가 업데이트되면 Cache-Control 헤더나 버전 관리를 사용하여 CDN 캐시를 새로 고칩니다.
실시간 요청 처리:
CDN은 캐시에 없는 요청에 대해서만 원본 서버로 데이터를 요청합니다. 이후 동일한 요청이 있을 경우 캐시에서 바로 처리됩니다.
4. CDN을 예로 든 캐시 설명 구조
캐시의 목적
"캐시는 자주 요청되는 데이터를 사용자와 가까운 곳에 저장하여 빠르게 제공하기 위해 사용됩니다. 예를 들어, CDN은 전 세계 여러 지역에 캐시 서버를 배포하여 사용자가 요청한 콘텐츠를 더 가까운 서버에서 제공합니다."
캐시의 작동 원리
"CDN은 캐시된 데이터를 제공할 때 원본 서버에 직접 요청하지 않기 때문에 응답 시간이 단축되고, 서버 부하가 줄어듭니다. 사용자는 최신 콘텐츠를 빠르게 제공받을 수 있습니다."
캐시의 갱신
"CDN에서 캐시된 데이터는 특정 기간(TTL) 동안 유효합니다. 데이터가 변경되면 새로운 데이터를 원본 서버에서 가져와 캐시를 업데이트합니다."
캐시와 실시간 처리
"CDN은 동적 콘텐츠를 실시간으로 요청할 때도, 기존 데이터를 캐시하여 재사용하므로 효율성을 높입니다."
5. 예제 시나리오
웹사이트에 CDN이 적용된 경우
사용자가 웹사이트에 접속.
브라우저는 이미지와 CSS를 다운로드:
CDN 서버에서 캐시된 데이터 제공.
개발자가 CSS 파일을 업데이트:
캐시 무효화를 통해 CDN 캐시가 갱신.
다음 요청부터는 최신 데이터 제공.
6. CDN의 캐시 장점
속도 향상:
사용자와 가까운 서버에서 데이터를 제공하므로 지연 시간이 줄어듭니다.
원본 서버 부하 감소:
CDN이 트래픽을 분산시켜 서버의 과부하를 방지합니다.
대역폭 절감:
동일한 데이터를 여러 번 요청할 필요가 없어 네트워크 비용을 줄입니다.
높은 가용성:
분산된 캐시 서버 덕분에 서버 장애에도 데이터 제공이 가능합니다.
캐시 무효화 전략(Cache Invalidation Strategies)
캐시 무효화는 캐시에 저장된 데이터가 더 이상 유효하지 않거나 최신이 아닐 때, 이를 제거하거나 업데이트하여 시스템의 일관성을 유지하는 과정입니다. 적절한 캐시 무효화는 데이터 정확성을 보장하면서도 성능을 유지하는 데 필수적입니다.
캐시 무효화 주요 전략
1. 수동 무효화(Manual Invalidation)
데이터가 변경될 때 개발자가 명시적으로 캐시를 무효화하는 방법.
주로 애플리케이션 로직에서 명시적으로 수행.
예시:
사용 사례:
데이터베이스에서 특정 사용자의 정보를 업데이트한 후 관련 캐시를 삭제.
2. TTL(Time-To-Live) 기반 무효화
캐시에 저장된 데이터가 지정된 시간이 지나면 자동으로 만료됩니다.
데이터가 최신일 필요는 없지만 빈번히 갱신되지 않아도 되는 경우 유용.
예시:
설정된
max-age=3600
은 데이터가 1시간(3600초) 동안 유효함을 나타냄.사용 사례:
뉴스 웹사이트에서 자주 변경되지 않는 기사 데이터를 캐싱.
3. Write-Through Cache
데이터베이스에 쓰기 작업이 수행될 때 캐시에도 동시에 업데이트하는 전략.
데이터가 항상 최신 상태를 유지.
예시:
사용 사례:
사용자 프로필 업데이트와 같이 항상 최신 상태가 필요한 데이터.
4. Write-Behind Cache
데이터는 먼저 캐시에 저장되고 일정 시간 후에 데이터베이스에 동기화.
데이터베이스에 대한 쓰기 작업이 지연될 수 있으나 캐시 접근 속도는 빠름.
예시:
사용 사례:
실시간 성능이 중요한 경우(예: 채팅 애플리케이션).
5. Cache Eviction(캐시 제거)
캐시가 가득 찬 경우, 오래된 데이터를 제거하여 새로운 데이터를 저장.
대표적인 정책:
LRU (Least Recently Used): 가장 오래된 데이터 제거.
LFU (Least Frequently Used): 사용 빈도가 낮은 데이터 제거.
FIFO (First-In-First-Out): 가장 먼저 들어온 데이터를 제거.
예시: Redis에서 LRU 정책을 설정:
6. Tag-Based Invalidations
캐시에 태그를 사용하여 관련된 여러 데이터를 그룹으로 묶고 한 번에 무효화.
특정 태그와 연관된 모든 데이터를 무효화 가능.
예시:
사용 사례:
뉴스 섹션의 모든 기사가 갱신되었을 때 캐시 무효화.
캐시 무효화 전략 적용 예제
1. 쇼핑몰 상품 정보
시나리오: 상품 정보가 캐시에 저장되어 있고, 상품 가격이 변경될 경우 캐시도 갱신되어야 함.
전략:
상품이 변경될 때 수동 무효화:
2. 사용자 프로필 업데이트
시나리오: 사용자가 프로필 사진을 변경했을 때 이전 프로필 사진 캐시 무효화.
전략:
Write-Through Cache:
3. 블로그 게시물
시나리오: 블로그 게시물은 자주 변경되지 않으나, 새로운 댓글이 추가되면 관련 데이터를 갱신.
전략:
TTL 기반 + 수동 무효화:
요약
캐시 무효화는 성능 최적화와 데이터 일관성을 유지하는 데 필수적입니다.
선택하는 전략은 애플리케이션 요구사항(데이터 일관성, 갱신 빈도, 캐시 크기 등)에 따라 달라집니다.
실시간성이 중요한 경우 Write-Through, 업데이트 빈도가 적으면 TTL 기반 무효화가 적합합니다.
. ServletInputStream
과 req.getInputStream()
ServletInputStream
과 req.getInputStream()
ServletInputStream
이란?
**
ServletInputStream
**은 HTTP 요청 본문(request body)을 읽기 위해 제공되는 입력 스트림입니다.클라이언트가 전송한 데이터(예: JSON, XML, 텍스트)를 서블릿에서 처리하기 위해 사용됩니다.
req.getInputStream()
메서드를 호출하여ServletInputStream
객체를 얻을 수 있습니다.
사용 시 주의점
본문 데이터를 한 번만 읽을 수 있음:
ServletInputStream
은 스트림이므로, 한 번 읽으면 다시 읽을 수 없습니다.데이터를 여러 번 처리하려면 한 번 읽은 데이터를 저장하거나 가공해야 합니다.
Content-Type 확인:
클라이언트가 전송한 데이터 형식(JSON, XML 등)에 맞는
Content-Type
헤더를 확인하고 처리해야 합니다.
사용 예제
설명:
StreamUtils.copyToString
: 스프링 유틸리티 클래스로, InputStream의 데이터를 문자열로 변환합니다.StandardCharsets.UTF_8
: 데이터 인코딩을 UTF-8로 지정.
2. ObjectMapper
(Jackson 라이브러리)
ObjectMapper
(Jackson 라이브러리)ObjectMapper
란?
**
ObjectMapper
**는 Jackson 라이브러리에서 제공하는 클래스입니다.JSON 데이터를 Java 객체로 변환하거나(Java로 deserialize) Java 객체를 JSON으로 변환(serialize)하는 데 사용됩니다.
주요 역할
JSON → Java 객체 변환:
클라이언트가 전송한 JSON 데이터를 Java 객체로 매핑.
예:
{"userId":"john", "age":25}
→User
클래스.
Java 객체 → JSON 변환:
Java 객체를 JSON 문자열로 변환하여 클라이언트에 응답.
예:
User
객체 →{"userId":"john", "age":25}
.
사용법
1. JSON → Java 객체
readValue()
:JSON 문자열을 Java 객체로 변환.
첫 번째 매개변수: JSON 문자열.
두 번째 매개변수: 변환할 Java 클래스 타입.
2. Java 객체 → JSON
writeValueAsString()
:Java 객체를 JSON 문자열로 변환.
Last updated