Ktor Framework

Ktor is designed around three main pillars:

1. Unopinionated: Ktor does not force specific technologies for logging, persistence, or serialization. It uses a unified interception mechanism to install features into an application, allowing you to build arbitrary pipelines. It can be hosted in servlet containers (like Tomcat) or standalone (using Netty or Jetty).
2. Asynchronous: The framework and its API are built on Kotlin coroutines, providing an asynchronous programming model. All host implementations use asynchronous I/O to prevent thread blocking.
3. Testable: Ktor provides a special test environment that emulates a web server without actual networking. This allows for high-performance integration testing without heavy mocking.

If you are using Gradle, you can run your embedded web server by executing the following command in your terminal:

./gradlew run

To enable build scans and remote build cache features, you must first authenticate. Run the :provisionDevelocityAccessKey task via Gradle to log in using your Google work account. Once provisioned, build scans will be automatically published after each build, and Gradle will utilize the remote build caches to accelerate local builds.

./gradlew :provisionDevelocityAccessKey

The build-logic project contains shared build logic for Ktor subprojects. Instead of using buildSrc, it uses Gradle composite builds to ensure that changes to the build logic do not cause the entire project to become out-of-date.

To use this shared logic in your project, you must include the build-logic directory as a composite build in your root settings.gradle.kts file.

// <root project dir>/settings.gradle.kts
includeBuild("build-logic")

Once build-logic is included via includeBuild in your settings.gradle.kts, you can apply the shared Ktor build configuration to your root build.gradle.kts using the ktorbuild.base plugin ID.

// <root project dir>/build.gradle.kts
plugins {
    id("ktorbuild.base")
}

The following features and management functions are deprecated in Ktor 1.6.x:

• ContentNegotiation constructor: Do not call the constructor explicitly. Instead, pass configuration options during the installation of the ContentNegotiation plugin.
• Feature Uninstallation: The functions uninstallAllFeatures, uninstall, and uninstallFeature are deprecated. There are currently no direct replacements for these functions in 1.6.x.

When using basic or digest authentication providers in Ktor 1.6.x, several properties have been deprecated in favor of more explicit functions and data classes:

• Use the sendWithoutRequest() function instead of the sendWithoutRequest property.
• Use the credentials() function instead of the username and password properties. The credentials() function accepts BasicAuthCredentials or DigestAuthCredentials data classes.

For low-level byte operations in Ktor 1.6.x, use the following replacements:

• Byte Order: ByteChannelSequentialBase.readByteOrder and ByteChannelSequentialBase.writeByOrder are deprecated. Read/write using big endian, and if necessary, call the ByteChannelSequentialBase.reverseByteOrder() extension function.
• Buffers: IoBuffer is deprecated. Use ChunkBuffer instead.
• Input/Output: AbstractInput and AbstractOutput are deprecated and will be merged with Input and Output respectively in version 2.0.0.

To use Ktor, add the necessary dependencies to your build configuration. You can use Maven Central as your repository. For a standard Netty server implementation, add io.ktor:ktor-server-netty to your dependencies.

repositories {
    mavenCentral()
}

dependencies {
    implementation("io.ktor:ktor-server-netty:$ktor_version")
}

The Ktor Gradle Plugin can be used to manage the Bill of Materials (BOM), run specific tasks, and handle deployment. When using the plugin, you can omit the version in your dependency declarations as the plugin manages the compatible versions.

plugins {
    id("io.ktor.plugin") version "3.1.1"
}

dependencies {
    implementation("io.ktor:ktor-server-netty")
}

The following APIs in Ktor 1.6.x are deprecated and should be replaced to ensure compatibility with future versions:

• TestApplicationCall.requestHandled: Instead of checking if a request was handled, validate the specific status, header, or content of the request depending on your test case.
• ApplicationCall.locationOrNull: Use ApplicationCall.location instead.