클라이언트 의존성 추가하기
프로젝트에서 Ktor HTTP 클라이언트를 사용하려면, 저장소를 구성하고 다음 의존성들을 추가해야 합니다:
ktor-client-core는 핵심 Ktor 클라이언트 기능을 포함합니다.엔진은 네트워크 요청을 처리하는 데 사용됩니다. 특정 플랫폼은 네트워크 요청을 처리하기 위해 특정 엔진이 필요할 수 있습니다.
(선택 사항) 로깅 의존성(Logging dependency)
구조화되고 유연한 로깅 기능을 제공하기 위해 로깅 프레임워크를 제공합니다.
(선택 사항) 플러그인 의존성(Plugin dependency)
플러그인은 특정 기능으로 클라이언트를 확장하는 데 사용됩니다.
Ktor 의존성을 추가하기 전에, 이 프로젝트의 저장소를 구성해야 합니다:
프로덕션(Production)
Ktor의 프로덕션 릴리스는 Maven 중앙 저장소(Maven central repository)에서 사용할 수 있습니다. 다음과 같이 빌드 스크립트에 이 저장소를 선언할 수 있습니다:
조기 액세스 프로그램 (EAP)
Ktor의 EAP 버전에 접근하려면, Space 저장소를 참조해야 합니다:
KotlinGroovyXMLKtor EAP는 Kotlin 개발(dev) 저장소가 필요할 수 있습니다:
KotlinGroovyXML
의존성 추가
다양한 플랫폼을 위해, Ktor는
ktor-client-core-jvm또는ktor-client-core-js와 같이-jvm또는-js와 같은 접미사가 붙은 플랫폼별 아티팩트를 제공합니다. Gradle은 주어진 플랫폼에 적합한 아티팩트를 자동으로 해결하지만, Maven은 이 기능을 지원하지 않습니다. 즉, Maven의 경우 플랫폼별 접미사를 수동으로 추가해야 합니다.
클라이언트 의존성
주요 클라이언트 기능은 ktor-client-core 아티팩트에서 사용할 수 있습니다. 빌드 시스템에 따라 다음과 같은 방식으로 추가할 수 있습니다:
$ktor_version을 필요한 Ktor 버전(예: 3.3.3)으로 교체할 수 있습니다.
멀티플랫폼
멀티플랫폼 프로젝트의 경우, gradle/libs.versions.toml 파일에 Ktor 버전과 ktor-client-core 아티팩트를 정의할 수 있습니다:
[versions]
ktor = "3.4.0"
[libraries]
ktor-client-core = { module = "io.ktor:ktor-client-core", version.ref = "ktor" }그런 다음, commonMain 소스 세트에 ktor-client-core를 의존성으로 추가합니다:
sourceSets {
commonMain.dependencies {
implementation(libs.ktor.client.core)
}
}엔진 의존성
엔진은 네트워크 요청을 처리하는 역할을 담당합니다. Apache, CIO, Android, iOS 등 다양한 플랫폼에서 사용할 수 있는 서로 다른 클라이언트 엔진들이 있습니다. 예를 들어, 다음과 같이 CIO 엔진 의존성을 추가할 수 있습니다:
멀티플랫폼
멀티플랫폼 프로젝트의 경우, 해당 소스 세트에 필요한 엔진에 대한 의존성을 추가해야 합니다.
예를 들어, Android용 OkHttp 엔진 의존성을 추가하려면 먼저 gradle/libs.versions.toml 파일에 Ktor 버전과 ktor-client-okhttp 아티팩트를 정의할 수 있습니다:
[versions]
ktor = "3.4.0"
[libraries]
ktor-client-okhttp = { module = "io.ktor:ktor-client-okhttp", version.ref = "ktor" }그런 다음, androidMain 소스 세트에 ktor-client-okhttp를 의존성으로 추가합니다:
sourceSets {
androidMain.dependencies {
implementation(libs.ktor.client.okhttp)
}
}특정 엔진에 필요한 전체 의존성 목록은 엔진 의존성 추가하기를 참조하세요.
로깅 의존성
JVM에서 Ktor는 로깅을 위한 추상화 계층으로 Simple Logging Facade for Java (SLF4J)를 사용합니다. SLF4J는 로깅 API를 기본 로깅 구현과 분리하여, 애플리케이션의 요구 사항에 가장 적합한 로깅 프레임워크를 통합할 수 있게 해줍니다. 일반적인 선택으로는 Logback 또는 Log4j가 있습니다. 프레임워크가 제공되지 않으면 SLF4J는 기본적으로 no-operation (NOP) 구현을 사용하며, 이는 사실상 로깅을 비활성화합니다.
로깅을 활성화하려면 Logback과 같이 필요한 SLF4J 구현이 포함된 아티팩트를 포함하세요:
Ktor에서의 로깅에 대한 자세한 정보는 Ktor 클라이언트의 로깅을 참조하세요.
플러그인 의존성
Ktor를 사용하면 인증(authorization) 및 직렬화(serialization)와 같이 기본적으로 제공되지 않는 추가 클라이언트 기능(플러그인)을 사용할 수 있습니다. 이들 중 일부는 별도의 아티팩트로 제공됩니다. 필요한 플러그인에 대한 주제에서 어떤 의존성이 필요한지 확인할 수 있습니다.
멀티플랫폼 프로젝트의 경우, 플러그인 의존성은
commonMain소스 세트에 추가되어야 합니다. 일부 플러그인은 특정 플랫폼에 대해 제한 사항이 있을 수 있음에 유의하세요.
Ktor 버전 일관성 보장하기
Ktor BOM 의존성 사용하기
Ktor BOM을 사용하면 각 의존성에 대해 버전을 개별적으로 지정하지 않고도 모든 Ktor 모듈이 동일하고 일관된 버전을 사용하도록 보장할 수 있습니다.
Ktor BOM 의존성을 추가하려면 다음과 같이 빌드 스크립트에 선언하세요:
게시된 버전 카탈로그(version catalog)를 사용하여 Ktor 의존성 선언을 중앙 집중화할 수도 있습니다. 이 방식은 다음과 같은 이점을 제공합니다:
- 자체 카탈로그에서 Ktor 버전을 수동으로 선언할 필요가 없습니다.
- 단일 네임스페이스 아래 모든 Ktor 모듈을 노출합니다.
카탈로그를 선언하려면,
그런 다음 모듈의