What does Ktor's Resources plugin change about how routes are declared and handled?

## The problem it solves The default routing DSL identifies routes by strings and hands you a `Parameters` multimap. That is flexible and readable, but it has two soft spots. First, the link between the template and the reads is textual: rename `{id}` to `{userId}` in the path and `call.parameters["id"]` compiles fine and returns null at runtime. Second, every URL you build elsewhere — a redirect, a `Location` header, a link in a response body — is string concatenation that no one checks against the route that will receive it. ## Declaring resources The Resources plugin turns routes into types. Add the resources artifact and the kotlinx.serialization compiler plugin, then `install(Resources)` in your module. A route becomes a class: `@Serializable @Resource("/articles") class Articles(val sort: String? = "new")` The annotation carries the path template. Constructor properties that appear in the template are bound from the path; the rest are bound from the query string. Nullability and defaults describe optionality, which is why the type declaration is the whole contract — there is no separate validation step for presence. Nesting composes through a parent property: `@Resource("{id}") class Id(val parent: Articles = Articles(), val id: Long)` declared inside `Articles` yields `/articles/{id}`, with `id` typed as `Long`. A request whose id is not numeric fails to deserialize into the class, which is the typed equivalent of the manual `toLongOrNull()` branch you would otherwise write. ## Handling and building Handlers are the generic overloads of the familiar verbs: `get<Articles> { articles -> call.respond(repo.list(articles.sort)) }` The lambda parameter is the populated instance. Rename a property and every handler that reads it stops compiling — the failure moves from runtime to build time, which is the main argument for the plugin. The reverse direction is `href`: `href(Articles.Id(id = 42))` renders the path for that instance, query parameters included. Redirects, hypermedia links and tests stop hardcoding paths, so changing a route's template updates every URL that points at it. ## Sharing with the client The same annotated classes work with Ktor's client-side resources support, so a Kotlin consumer can issue a request from a route instance rather than a string. In a codebase where both sides are Kotlin and can share a module, that turns the route table into a compile-checked contract between them. That is the strongest case for adopting the plugin and the reason it shows up mostly in Kotlin-multiplatform-shaped projects. ## Costs and when to skip it It is not free. You take on the serialization compiler plugin, an extra artifact, and a declaration style that is heavier than a one-line `get("/health")`. Route classes add indirection for anyone reading the code who does not know the plugin, and unusual path shapes are more awkward to express than in a raw template. For a small service, or one whose consumers are not Kotlin, the string DSL with disciplined parameter parsing is a perfectly defensible choice — and mixing both in one application is legal, since resource routes and string routes live in the same tree. ## Lineage The idea predates the current plugin: Ktor 1.x shipped an experimental Locations feature using an `@Location` annotation with the same intent. Resources is its successor, built on kotlinx.serialization rather than reflection. If you meet `@Location` in an existing codebase, you are looking at the older mechanism, and the migration is mostly mechanical — annotate the classes `@Serializable`, swap the annotation, and install the new plugin. ## What interviewers listen for The question is usually a differentiator rather than a gate, so the answer they want is a comparison, not a tutorial: what the plugin buys (typed parameters, compile-time coupling between routes and handlers, generated URLs), what it costs (serialization plugin, extra ceremony), and a clear-headed statement of when you would not bother. A candidate who presents it as strictly better than the string DSL has usually not shipped with it.