Ktor ContentNegotiation converter trade-off: kotlinx.serialization strictness versus Jackson unknown-field defaults

Direct Answer

For a rolling upgrade where newer clients send extra JSON fields, Jackson with the Kotlin module registered is the lower-friction default. Its permissive unknown-field behavior works immediately without configuration changes. kotlinx.serialization requires explicit ignoreUnknownKeys = true (global or per-class) to achieve the same tolerance.

Default Behaviors and Ktor Configuration

kotlinx.serialization (strict by default)

• Unknown keys cause deserialization failure unless opted out.
• In Ktor: install(ContentNegotiation) { kotlinxSerialization(Json { ignoreUnknownKeys = true }) }
• Can also annotate data classes: @Serializable(ignoreUnknownKeys = true)
• Setting is compile-time baked into generated serializers; cannot toggle per-request.

Jackson (permissive by default)

• DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES = false is the default.
• In Ktor: install(ContentNegotiation) { jackson { registerModule(KotlinModule()) } }
• Kotlin module must be registered or data classes with default parameters fail.
• To enforce strictness: jackson { enable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES) }

Interaction with Ktor Converter APIs

Both converter APIs have been stable since Ktor 2.0. The ktor-serialization-kotlinx-json and ktor-serialization-jackson artifacts must match the Ktor core version. No Ktor version blocks either configuration. The trade-off is localized to the install(ContentNegotiation) block, though switching libraries later requires rewriting annotations and custom serializers.

Verification That Extra Fields Are Tolerated Without Masking Drift

Neither library logs dropped fields by default. To detect schema drift without failing requests:

1. Integration test: Send JSON with extra fields not in the data class; assert 200 OK and correct known-field deserialization. Run against both converter configurations.
2. Drift detection interceptor: Add a Ktor interceptor that compares incoming payload keys against expected model keys (via reflection or JSON Schema). Log/metric unknown keys.
3. Jackson-specific: Register a custom DeserializationProblemHandler to capture dropped fields.
4. kotlinx.serialization-specific: No built-in unknown-key logging; the interceptor approach is required.
5. Verify Kotlin module registration: Check jackson.registeredModuleIds contains kotlin-module; test deserialization of a data class with default parameter values.

One Missing Diagnostic Detail

Does your service use polymorphic deserialization (sealed class hierarchies or subtype handling)? This changes the recommendation because kotlinx.serialization and Jackson handle polymorphism very differently (@Serializable + typeOf() vs @JsonTypeInfo/@JsonSubTypes), and migration cost between them is high for type hierarchies.