Learning Ktor Through a Spring Boot Lens. Part 2

This article continues our exploration of Ktor from the perspective of a developer familiar with Spring Boot. In the first part, we laid the groundwork by discussing Application Setup, Server Engines, Configuration, and Dependency Injection. Now, we move forward to more advanced aspects of web application development with Ktor. In this section, I will guide you through HTTP Request Handling & Exception Handling, HTTP Clients, and Testing, showcasing how Ktor’s native features streamline these processes.

You can find it here if you haven’t yet read the first part of this series. It provides essential context and comparisons that will help you fully grasp the topics covered in this continuation.

Handling HTTP requests

One of the core responsibilities of web applications is handling HTTP requests by exposing the REST endpoints. As a result, every web framework provides mechanisms for processing requests in both successful and error scenarios.

As with other aspects, Spring Boot and Ktor take different approaches that reflect their distinct philosophies. This chapter explores how each framework enables you to define and organize routes, handle request parameters, and react in exceptional cases.

Routes defining and organization

Spring Boot

Spring Boot uses annotation-based controllers, which can be organized according to the endpoints they expose. The framework automatically discovers and registers these controllers at startup through component scanning.

@RestController
@RequestMapping("/api/users")
class UserController(private val userService: UserService) {

    @GetMapping("/{id}")
    fun getUserById(@PathVariable id: Long): User = userService.getUserById(id)

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    fun createUser(@RequestBody user: User): User = userService.createUser(user)

    @DeleteMapping("/{id}")
    @ResponseStatus(HttpStatus.NO_CONTENT)
    fun deleteUser(@PathVariable id: Long) = userService.deleteUser(id)
}

@RestController 
@RequestMapping("/api/orders") 
class OrderController(private val orderService: OrderService) {

    @GetMapping("/{id}")
    fun getOrderById(@PathVariable id: Long): User = orderService.getOrderByIt(id)
}

Ktor

Ktor's routing system uses Kotlin's powerful DSL capabilities, offering a fluent, hierarchical approach that allows routes to be organized in a nested structure that naturally maps to URL paths. Unlike annotation-based frameworks, Ktor encourages modularization through extension functions, enabling developers to group related routes into separate files.

// Application.kt
fun Application.configureRouting() {
    routing {
        userRoutes()
        orderRoutes()
    }
}

// UserRoutes.kt
fun Route.userRoutes() {
    route("/api") {
        route("/users") {

            get("/{id}") {
                val id = call.parameters["id"]?.toLongOrNull() 
                        ?: return@get call.respondText("Invalid ID", status = BadRequest)

                val user = userService.getUserById(id)
                if (user != null) {
                     call.respond(user)
                } else {
                    call.respond(HttpStatusCode.NotFound)
                }
           }

            post {
                val user = call.receive<User>()
                val createdUser = userService.createUser(user)
                call.respond(HttpStatusCode.Created, createdUser)
            }

            delete("/{id}") {
                val id = call.parameters["id"]?.toLongOrNull() 
                    ?: return@delete call.respondText("Invalid ID", status = BadRequest)

                userService.deleteUser(id)
                call.respond(HttpStatusCode.NoContent)
            }
        }
    }
}

// OrderRoutes.kt
fun Route.orderRoutes() {
    route("/api/orders") {

        get("/{id}") {
            val id = call.parameters["id"]?.toLongOrNull() 
                    ?: return@get call.respondText("Invalid ID", status = BadRequest)

            val user = orderService.getOrderById(id)
            if (user != null) {
                call.respond(user)
            } else {
                call.respond(HttpStatusCode.NotFound)
            }
        }
    }
}

In the Application.configureRouting() function, the routing() method is called, which installs the Routing plugin into the Ktor application. Within the lambda body, two extension functions are executed to define routes for Users and Orders.

Route definitions begin by specifying the path using, e.g., route("/api/users") DSL function. In the associated lambda, endpoints are declared using functions corresponding to HTTP methods (e.g., get, post, put, etc.).

To handle incoming requests and send responses, you typically work with the call property, an instance of RoutingCall. It allows you to:

• Read the path variable, e.g., call.parameters["id"]
• Read the request parameter, e.g., call.request.queryParameters["name"]
• Read the request payload, e.g., call.receive()
• Respond with response, e.g., call.respond(HttpStatusCode.NotFound)

Type-safe routing

Spring Boot

Spring Boot's controller-based approach provides type safety for request and response bodies; however, path variables and request parameters rely on string-based mapping, which is resolved in runtime and thus is not type-safe.

@GetMapping("/users/{id}") // not type safe
fun getUser(@PathVariable id: Long): User {
    return userService.getUser(id)
}

Ktor

Ktor offers a more type-safe approach with the Resources feature. It elevates routing beyond string-based path definitions by representing your API structure as a class hierarchy, where each route becomes a strongly typed object with proper parameter types.

This approach provides compile-time verification of route parameters and paths, eliminating common runtime errors while enabling type-safe URL generation through the href() function. Refactoring becomes even safer and more manageable by modeling routes as classes instead of strings. All you need to do is define the class hierarchy that defines your API and use it in the routing definition.

// Define route structure as a class hierarchy
@Resource("/api/users")
class Users {

    @Resource("/{id}")
    class Id(val parent: Users, val id: Long) {

        @Resource("/orders")
        class Orders(val parent: Id)
    }

    @Resource("/search")
    class Search(val parent: Users, val sort: String? = "ASC")
}

// Use type-safe routing
routing {
    get<Users> {
        call.respond(userService.getAllUsers())
    }

    get<Users.Id> { route ->
        call.respond(userService.getUser(route.id))
    }

    get<Users.Id.Orders> { route ->
        call.respond(orderService.getOrdersForUser(route.parent.id))
    }

    get<Users.Search> { route ->
        call.respond(userService.searchUsers(route.sort))
    }
}

// Generate URLs type-safely
val usersUrl = application.href(Users()) // /api/users
val userUrl = application.href(Users.Id(Users(), 123)) // /api/users/123

To enable Resources in Ktor you need to add the following dependency and install Resources plugin:

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

fun Application.myAppModule() {
    install(Resources)
}

Exception handling

Spring Boot

Spring Boot provides various exception handling mechanisms, including global exception handling using the @ControllerAdvice annotation, more granulated controller-level handling with @ExceptionHandler, implementing HandlerExceptionResolver, extending AbstractHandlerExceptionResolver, or utilizing the ErrorController interface.

Below is an example of a global approach using @ControllerAdvice:

@RestControllerAdvice
class GlobalExceptionHandler {

    @ExceptionHandler(UserNotFoundException::class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    fun handleUserNotFound(e: UserNotFoundException): ErrorResponse {
        return ErrorResponse.from(e)
    }

    @ExceptionHandler(ValidationException::class)
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    fun handleValidation(e: ValidationException): ErrorResponse {
        return ErrorResponse.from(e)
    }

    @ExceptionHandler(Exception::class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    fun handleGeneric(e: Exception): ErrorResponse> {
        return ErrorResponse.from(e)
    }
}

Ktor

Ktor provides a mechanism for handling and responding appropriately to exceptions thrown within your application. As is typical in Ktor, this feature must be enabled using the install() function, and the appropriate dependency must be added.

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

fun Application.configureErrorHandling() {
    install(StatusPages) {
        exception<UserNotFoundException> { call, cause ->
            call.respond(HttpStatusCode.NotFound, ErrorResponse.from(cause))
        }

        exception<ValidationException> { call, cause ->
            call.respond(HttpStatusCode.BadRequest, ErrorResponse.from(cause))
        }

        exception<Throwable> { call, cause ->
            call.respond(HttpStatusCode.InternalServerError, ErrorResponse.from("An unexpected error occurred"))
        }
    }
}

Http Clients

There are very few, if any, modern web applications that only expose an API without needing to communicate with other systems. This becomes especially crucial in a microservice architecture, where services often need to interact with one another to complete a business operation.

The most common pattern for such communication is a synchronous HTTP call, which requires an HTTP client within the application. Both Spring Boot and Ktor provide powerful HTTP client libraries but follow different philosophies and approaches. In this chapter, I will examine how those approaches differ.

Request and response handling

Spring Boot

Spring Boot offers various HTTP client options. The first approach is a synchronous client, which involves two libraries - the older, well-known RestTemplate, which offers a template method API, and the newer RestClient, which offers a modern, fluent API. If you need an asynchronous approach, you can use WebClient, which provides a reactive, non-blocking approach ideal for high-throughput systems.

Both clients support comprehensive features like request/response manipulation, error handling, and automatic serialization/deserialization. Still WebClient is generally preferred for new development due to its modern API design and better integration with Spring's reactive ecosystem. I will use WebClient to compare the features of Spring Boot's HTTP client with Ktor's.

This is how to call the /resources/{id} endpoint with the authorization header, the Accept header, and handle the response using WebClient.

fun getResource(id: Long): Mono<Resource> =
    webClient.get()
        .uri("/resources/{id}", id)
        .header(HttpHeaders.AUTHORIZATION, "Bearer token")
        .accept(MediaType.APPLICATION_JSON)
        .retrieve()
        .bodyToMono(Resource::class.java)

Ktor

Ktor's HTTP client uses Kotlin's suspend functions and DSL to provide a concise syntax for executing requests, where the HTTP method becomes a direct function call with a request builder lambda for configuration. To execute the endpoint from the previous example, passing authorization and Accept headers, you need to use the following code.

suspend fun getResource(id: Long): Resource =  
    client.get("https://api.example.com/resources/$id") {
        header(HttpHeaders.Authorization, "Bearer token")
        accept(ContentType.Application.Json)
    }.body()

Http client configuration

The examples above assume that the HTTP clients are already configured. However, you must set up the appropriate configuration before using them. In this section, I’ll describe how the configuration approaches differ between the frameworks.

Spring Boot

Spring Boot simplifies WebClient configuration through auto-configuration, automatically registering a WebClient’s builder bean that you can inject and customize with minimal code. While you can create a fully customized WebClient bean manually, in many cases you can leverage the pre-configured builder and just apply your specific customizations.

Properties like connection timeouts and response sizes are configurable through application properties rather than code. However, if needed you can also configure WebClient manually and create your own customized bean.

@Configuration
class WebClientConfig {

    @Bean
    fun webClient(): WebClient {
        return WebClient.builder()
            .baseUrl("https://api.example.com")
            .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
            .clientConnector(ReactorClientHttpConnector(HttpClient.create()
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
                .responseTimeout(Duration.ofMillis(5000))
                .doOnConnected { conn ->
                    conn.addHandlerLast(ReadTimeoutHandler(5, TimeUnit.SECONDS))
                    conn.addHandlerLast(WriteTimeoutHandler(5, TimeUnit.SECONDS))
                }
            ))
            .build()
    }
}

To operate, WebClient requires an underlying HTTP client library. By default, it works with Reactor Netty. It can be exchanged to Jetty's reactive HTTP client when jetty-reactive-httpclient is present on a classpath, or Apache HttpComponents when httpclient5-reactive is available. Spring Boot automatically detects and configures the appropriate connector based on your dependencies.

Ktor

Ktor's HTTP client offers a flexible, plugin-based configuration system using a DSL that allows you to install features like logging, timeout handling, retry mechanism, and JSON serialization using concise and readable syntax. Every feature is by default disabled, and you have to explicitly enable it by installing the plugin and (usually) adding suitable dependencies.

The client supports multiple interchangeable engine implementations, including CIO (Coroutine-based I/O), which is Ktor's native engine optimized for Kotlin coroutines, Apache for legacy support, OkHttp for JVM and Android applications, Java's HttpClient for standard JVM applications, and platform-specific engines for JavaScript and Native targets, allowing you to choose the most appropriate implementation for your runtime environment while maintaining consistent API usage.

You can read more about client engines here.

You can use the following configuration to configure Ktor’s client to work with JSONs. This configuration logs all the request and response data, timeouts, and request retries.

val client = HttpClient(CIO) {

    // Install content negotiation plugin with JSON support
    install(ContentNegotiation) {
        json()
   }

    // Logging configuration
    install(Logging) {
        logger = Logger.DEFAULT
        level = LogLevel.ALL
    }

    // Timeouts configuration
    install(HttpTimeout) {
        requestTimeoutMillis = 5000
        connectTimeoutMillis = 5000
        socketTimeoutMillis = 5000
    }

    // Retries
    install(HttpRequestRetry) {
        retryOnServerErrors(maxRetries = 3)
        exponentialDelay()
    }

    // Engine-specific configuration
    engine {
        pipelining = true
        endpoint {
            connectTimeout = 5000
            socketTimeout = 5000
            requestTimeout = 5000
            keepAliveTime = 5000
        }
    }
}

Required dependencies:

implementation("io.ktor:ktor-server-content-negotiation:$ktor_version")
implementation("io.ktor:ktor-serialization-kotlinx-json:$ktor_version")
implementation("io.ktor:ktor-client-core:$ktor_version")
implementation("io.ktor:ktor-client-cio:$ktor_version")
implementation("ch.qos.logback:logback-classic:$logback_version")

Error handling

The first of the eight fallacies of distributed computing states that "the network is reliable." Since we know this isn't true, we must expect errors when making network calls using an HTTP client. Because this is a common concern, most HTTP client libraries, including those in Spring Boot and Ktor, provide built-in mechanisms for error handling. Let’s examine how they differ.

Spring Boot

Spring Boot's error handling for WebClient offers a declarative approach through the onStatus function, allowing developers to specify custom error handling logic based on HTTP status codes. The framework provides a comprehensive exception hierarchy where WebClientResponseException subtypes correspond to different error categories (4xx, 5xx), which can be caught and handled using standard exception handling techniques.

webClient.get()
    .uri("/resources/{id}", id)
    .retrieve()
    .onStatus({ it.is4xxClientError }) { response ->
        when (response.statusCode()) {
            HttpStatus.NOT_FOUND -> Mono.error(ResourceNotFoundException("Resource not found"))
            HttpStatus.UNAUTHORIZED -> Mono.error(UnauthorizedException("Unauthorized access"))
            else -> response.bodyToMono(String::class.java)
                .flatMap { Mono.error(ClientException("Client error: ${response.statusCode()}, body: $it")) }
        }
    }
    .onStatus({ it.is5xxServerError }) { response ->
        Mono.error(ServerException("Server error: ${response.statusCode()}"))
    }
    .bodyToMono(Resource::class.java)
    .onErrorResume(ResourceNotFoundException::class.java) { ex ->
        // Fallback logic
        Mono.just(Resource.notFound())
    }

Ktor

You have two options for handling errors when working with Ktor’s HTTP client. You can manage them programmatically by catching specific response validation exceptions, or you can use the dedicated HttpCallValidator plugin, which provides a mechanism for global error handling.

The first approach requires setting the “expectSuccess” flag to true, either on the HTTP client configuration or on the request level. It enables Ktor’s client to throw suitable exceptions on 4xx and 5xx status codes.

//  HTTP client configuration
val client = HttpClient(CIO) {
    expectSuccess = true
    // …
}

suspend fun getResource(id: Long): Result<Resource> {
    return try {
        val resource = client.get<Resource>("https://api.example.com/resources/$id")
        Result.success(resource)
    } catch (e: ClientRequestException) {
        // 4xx responses
        when (e.response.status.value) {
            404 -> Result.failure(ResourceNotFoundException("Resource not found"))
            401 -> Result.failure(UnauthorizedException("Unauthorized access"))
            else -> Result.failure(e)
        }
    } catch (e: ServerResponseException) {
        // 5xx responses
        Result.failure(ServerException("Server error: ${e.response.status.value}"))
    } catch (e: Exception) {
        // Connection, timeout, or other errors
        Result.failure(e)
    }
}

And this is how you can define the global handling using HttpCallValidator.

install(HttpCallValidator) {
    handleResponseExceptionWithRequest { exception, request ->
        when (exception) {
            is ClientRequestException -> {
                val response = exception.response
                if (response.status.value == 401) {
                    throw UserUnauthorizedException(exception)
                } else {
                    handleClientException(exception)
                }
            }
            is ServerResponseException -> {
                handleServerError(exception)
            }
            else -> throw exception
        }
    }
}

Testing

Testing is essential not only for verifying that your code meets requirements, but also for ensuring it behaves correctly as it evolves. This section considers many aspects, but for simplicity, I will focus on the three types of tests developers commonly use in their projects: unit, integration, and slice tests.

This chapter shows how these tests are typically implemented in Spring Boot and explains how to achieve the same results in Ktor using the Kotest framework. Since the purpose of this article is to provide an overview of these web frameworks, it doesn’t cover the full details of Kotest. However, if you want to learn more, check out our dedicated article: Kotest: The Kotlin Testing Framework You Will Love.

Unit tests

Spring Boot

Unit tests focus on verifying the behavior of individual classes or methods in isolation. They run quickly and help catch logic errors before dependencies and external systems come into play. Because unit tests operate at the class level, the Spring Boot framework does not provide any exceptional support for them. Typically, we implement unit tests using a testing library (JUnit, TestNG, Spock in Groovy, etc.) with Mockito to potentially stub dependencies of the tested class. The example below uses JUnit 5.

@ExtendWith(MockitoExtension::class)
class UserServiceTest {

    @Mock
    private lateinit var repo: UserRepository

    @InjectMocks
    private lateinit var systemUnderTest: UserService

    @Test
    fun `should return user when found`() {
        val user = User(1L, "Alice")
        whenever(repo.findById(1L)).thenReturn(Optional.of(user))

        val result = systemUnderTest.findById(1L)

        assertThat(result.name).isEqualTo("Alice")
        verify(repo).findById(1L)
    }

    @Test
    fun `should throw when not found`() {
        whenever(repo.findById(any())).thenReturn(Optional.empty())

        assertThatThrownBy { systemUnderTest.findById(42L) }
          .isInstanceOf(NotFoundException::class.java)
    }
}

Kotest / Koin

Like Spring Boot, Ktor doesn’t include any special features for unit testing. Depending on your dependency-injection framework, setting up unit tests may require a bit of extra boilerplate. For example, when using Koin (as described in earlier chapters), you need to start the Koin context and define a testing module that provides your mocked dependencies.

In the example below, I have defined a test module that uses a mocked UserRepository. The behavior of this mocked repository can be configured for each test case. In contrast, the system under test (UserService) is a real instance that receives the mocked repository through dependency injection. This allows you to control the repository's behavior to meet the specific requirements of each test.

class UserServiceTest : StringSpec(), KoinTest {
    private val testModule = module {
        single<UserRepository> { mockk(relaxed = true) }
        single { UserService(get()) }
    }

    private val repo: UserRepository by inject()
    private val systemUnderTest: UserService by inject()

    init {
        beforeSpec {
            startKoin { modules(testModule) }
        }
        afterSpec {
            stopKoin()
        }

        "should return user when found" {
            val user = User(1, "Alice")
            every { repo.getById(1) } returns user
            systemUnderTest.findById(1).name shouldBe "Alice"
            verify { repo.getById(1) }
        }

        "should throw exception when not found" {
            every { repo.getById(any()) } returns null
            shouldThrow<NotFoundException> { systemUnderTest.findById(42) }
        }
    }
}

Integration tests

Integration tests cover a larger slice of your application, usually booting up the whole context (including a real HTTP server, database connections, migrations, serialization, etc.) to verify that components work together correctly. Although they typically run more slowly than unit tests, they’re invaluable for catching configuration errors, runtime mismatches, and integration points that unit tests alone can’t expose.

Spring Boot

In Spring Boot, integration tests typically use the @SpringBootTest annotation to launch the full application context, including your controllers, services, repositories, and any embedded server or database configuration. These tests verify that your Spring beans are wired correctly, that configuration properties are applied, and that real components (e.g., JPA repositories against an embedded or test database) interact as expected. The following example verifies the user creation process in a Spring Boot application.

@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class UserIntegrationTest {

    @Autowired
    private lateinit var rest: TestRestTemplate

    @Test
    fun `create and fetch user`() {
        val newUser = mapOf("name" to "Alice")
        val create = rest.postForEntity("/users", newUser, UserDto::class.java)
        assertThat(create.statusCode).isEqualTo(HttpStatus.CREATED)

        val id = create.body!!.id
        val get = rest.getForEntity("/users/$id", UserDto::class.java)
        assertThat(get.body!!.name).isEqualTo("Alice")
    }
}

Ktor

In Ktor, integration tests typically use the built-in test engine (via testApplication { … }) to launch your modules and plugins in an in-memory server, then drive it with an HTTP client just as a real client would. You can hook in test databases (e.g., H2 or TestContainers) and run your migrations, but you must explicitly install and configure each feature in your test setup.

Unlike Spring Boot, which automatically boots the entire application context, Ktor integration tests start up faster and give you fine-grained control by explicitly installing and configuring each feature. Spring Boot tests favor convenience and broader coverage of your application’s auto-configured environment. Below example covers the test of creating a user in our application using an H2 in-memory database.

class UserIntegrationTest : StringSpec({
    "create and fetch user" {
        testApplication {
            environment {
                config = MapApplicationConfig(
                    "ktor.deployment.port" to "0",
                    "database.url" to "jdbc:h2:mem:test;DB_CLOSE_DELAY=-1",
                    "database.username" to "sa",
                    "database.password" to "XXX"
                )
            }
            application {
                myAppModule()
            }
            val client = createClient {
                install(io.ktor.client.plugins.contentnegotiation.ContentNegotiation) {
                    json()
                }
            }
            val createResp = client.post("/users") {
                contentType(ContentType.Application.Json)
                setBody(UserDto(name = "Alice"))
            }
            createResp.status shouldBe HttpStatusCode.Created
            val id = createResp.body<UserDto>().id
            // Fetch user
            val getResp = client.get("/users/$id")
            getResp.status shouldBe HttpStatusCode.OK
            getResp.body<UserDto>().name shouldBe "Alice"
        }
    }
})

Slice tests

Slice tests focus on a single layer or “slice” of your application, such as the web, service, or data layer. In - web applications, they are typically used to test controllers or routing without bringing up the entire application. They load only the beans and configuration needed for that slice while mocking out everything else. Thus, they run faster than full integration tests, yet still verify real interactions within that slice.

Spring Boot

In Spring Boot, slice tests use dedicated test annotations like @WebMvcTest, @DataJpaTest, or @RestClientTest, to load only the parts of the application context relevant to that layer, while mocking the rest. The code below verifies UserController using @WebMvcTest annotation, which brings up the controller slice and uses mocked UserService to confirm that the controller works correctly.

@WebMvcTest(UserController::class)
class UserControllerTest {

    @Autowired
    private lateinit var mvc: MockMvc

    @MockBean
    private lateinit var service: UserService

    @Test
    fun `should return user`() {
        given(service.findById(1L)).willReturn(User(1L, "Alice"))

        mvc.perform(get("/users/1"))
           .andExpect(status().isOk)
           .andExpect(jsonPath("$.name").value("Alice"))
    }
}

Ktor

Ktor doesn’t have a dedicated feature for slice tests. However, you can use the aforeused testApplication DSL to spin up only the specific modules or routes you want to verify, installing just specific plugins (e.g., ContentNegotiation, Authentication) and wiring in Koin overrides or mock dependencies for everything else.

It allows you to drive those slices directly to verify serialization, validation, and routing logic in isolation from the real database or external services. The example below uses testApplication DSL to install JSON content negotiation, define the Koin module with mocked UserService, and define user’s related routes only to test the routing slice.

class UserRoutesTest : StringSpec({
    "should return user" {
        val mockService = mockk<UserService>()
        every { mockService.findById(1) } returns User(1, "Alice")

        testApplication {
            install(ContentNegotiation) { json() }
            install(Koin) {
                modules(module { single { mockService } })
            }

            routing { userRoutes() }
            val response = client.get("/users/1")
            response.status shouldBe HttpStatusCode.OK
            response.body<UserDto>().name shouldBe "Alice"
        }
    }
})

Summary of Part 2

This section of the article aimed to introduce the Ktor framework, highlighting its key functionalities and drawing connections to familiar concepts from Spring Boot to streamline the learning process. Below is a summary of the topics covered and compared throughout the discussion:

HTTP Request Handling

• Spring Boot: Annotation-based controllers
• Ktor: DSL-based routing with extension functions and full type-safe routings

Exception Handling

• Spring Boot: Uses @ControllerAdvice and @ExceptionHandler
• Ktor: Uses StatusPages plugin with registered handlers

HTTP Clients

• Spring Boot: Offers RestTemplate and WebClient with declarative error handling
• Ktor: Uses suspend functions with plugin-based configuration and programmatic error handling

Testing

• Spring Boot: Uses JUnit 5 (or other JVM frameworks) with Mockito for unit tests, @WebMvcTest + MockMvc for slice tests of controllers (or similar for other slices), @SpringBootTest + TestRestTemplate for full integration tests.
• Ktor: Uses Kotest with MockK (and e.g. Koin for DI) for unit tests, the testApplication { … } DSL for both slice and integration tests, with in-process HTTP client and configurable application environment, which gives you better control on what you test, but requires more ceremony.

Although both parts of the article (Here you can read Part 1) cover many aspects, it doesn't address everything required when developing a web application with Ktor. Therefore, you'll likely need additional learning to use Ktor in your projects successfully. If you need support with development in Ktor or Kotlin in general, please check out our Kotlin development services and feel free to contact us.

Reviewed by: Szymon Winiarz and Rafał Wokacz