http4k: a Kotlin HTTP toolkit where the application is just a function

What problem http4k solves, and who it is aimed at

Most Kotlin and Java HTTP frameworks ask you to accept a container, a lifecycle and a set of annotations before you can return a response. http4k starts from the opposite end. The README states that http4k applications are "just Kotlin functions", and the echo server it gives as an example is a single lambda: a value of type HttpHandler that takes a Request and returns a Response. There is no framework object to subclass and no annotation processor in the path.

The audience follows from that choice. Teams that want to compose middleware by wrapping one function in another, that want the same handler exercised in a unit test and deployed behind a real server, and that want to compile to GraalVM and ship a small binary are the intended users. The repository topics name the same priorities directly: immutability, testability, typesafe, tdd.

The toolkit is not one artifact. The README describes http4k-core as a lightweight core library with a base HTTP implementation and JDK-based server and client implementations, with further servers, clients, serverless, templating and websockets capabilities in add-on modules. Everything in the platform is released under a single version, which removes the dependency-alignment problem that multi-module frameworks usually create.

One HttpHandler type from test to server to GraalVM

The mechanism is uniform typing. A server, a client and a fake all present the same shape, so code written against one can be exercised against another without a rewrite. The README's echo server shows the server side: the handler is bound to a concrete server implementation and started.

That binding is the part people miss. http4k-core ships Server and Client implementations based on JDK classes; other server backends live in add-on modules. Swapping SunHttp for another server is a change at the mount point, not a change inside the application logic. The same property is what lets the README describe mounting an app into a running server, into a serverless platform, or compiling it to GraalVM as a lightweight binary.

The platform has grown beyond core. http4k-connect is described as a lightweight API client toolkit with libraries for third-party cloud services and AI backends, plus Fake implementations for local testing. http4k-ai provides LLM adapters for OpenAI, Anthropic, Gemini, Azure and GitHub Models, LangChain4J integration and an agent framework, all testable in memory with Fakes. The through-line is the same: a real implementation and a fake implementation satisfy one interface, so tests do not need a network.

Installing http4k with Gradle and serving a first request

Installation goes through the http4k-bom platform, which pins every module to one version. The README shows the dependency block with a placeholder for the version, so substitute the release you intend to track.

dependencies {
    // install the platform...
    implementation(platform("org.http4k:http4k-bom:<LATEST_VERSION>"))

    // ...then choose any moduless but at least the core
    implementation("org.http4k:http4k-core")
}

Note the spelling in the README comment: "moduless". It is a typo in the source, not a Gradle feature. The important part is that the platform entry comes first and http4k-core is the minimum you need.

The README's echo server is the smallest real use. It defines a handler that copies the request body into a 200 response, binds it to the SunHttp server on port 8000, and starts it.

val app: HttpHandler = { request: Request -> Response(OK).body(request.body) }
val server = app.asServer(SunHttp(8000)).start()

After that runs, posting a body to port 8000 returns the same bytes with a 200 status. Because app is a plain value, you can call it directly in a test with a constructed Request and assert on the Response without starting the server at all. That is the whole point of the design, and it is worth trying before you build anything larger.

One scheduling detail belongs here rather than at the end. The README carries a distribution notice: from 1 October 2026, new releases of http4k will be published to Maven Central quarterly, while publication to maven.http4k.org continues on the normal 1-2 week cadence. Both channels are supported. If your build resolves only from Maven Central, you will see new versions less often than the project produces them.

Where http4k stops being the right tool

The functional model is a constraint as much as a feature. If your team expects a container to own configuration, dependency injection, transaction boundaries and a component scan, http4k hands you none of that. You assemble the pieces yourself. For a small service that is a benefit; for a large application with many teams contributing, the absence of a prescribed structure means you invent one, and the project does not tell you what it should look like.

The commercial split is the second boundary to understand before you commit. The README lists http4k-pro as premium, commercially licensed modules under the org.http4k.pro Maven group, covering Wiretap (OpenTelemetry capture and a developer console), X402/MPP payment protocols, Verify (build-time supply-chain verification), Hot Reload, and pro-tier MCP and A2A integrations. http4k Enterprise adds long-term stability of up to 24-month LTS, SLSA provenance, signed SBOMs, cosign signatures, priority support, license reporting and source access. If your requirements land on those features, the Apache-2.0 Community Edition is not the whole answer.

Licence metadata is worth checking rather than assuming. The repository's licence is reported as NOASSERTION by the hosting platform, while the README badge and the LICENSE and NOTICE files point at Apache License 2.0 for the Community Edition. The README states plainly that the Community Edition remains free and Apache-2.0 and on Maven Central. Treat the pro and Enterprise tiers as separate commercial terms and read them yourself; this is not legal advice.

http4k vs Ktor and Spring Boot: different starting points

The honest comparison is about where the abstraction sits. Spring Boot starts with an application context and builds HTTP on top of it; you get configuration, injection and a broad managed ecosystem, and you accept the container as the centre of the design. Ktor starts with a server and a routing DSL plus coroutine-based pipelines; it is a framework you configure and extend, and it brings its own plugin model.

http4k starts with a function type. The README's rationale page is where the project argues for that, and the practical difference is what you can do with the value. A handler can be called in a unit test, wrapped in middleware, mounted on a server, deployed to a serverless platform, or compiled to GraalVM, and none of those moves require the application code to know which one is happening. In Spring Boot or Ktor, the equivalent step usually means booting the framework or working within its test facilities.

The cost is symmetry. You get no routing DSL, no plugin registry and no opinion about project layout beyond what the add-on modules provide. Teams that value a prescribed structure will find http4k under-specified; teams that have been fighting a container to test a single endpoint will find it a relief. The http4k-connect and http4k-ai modules show the same trade applied to outbound calls and LLM providers: one interface, a real implementation, and a Fake for tests.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-24. Releases are frequent: 6.60.0.0 on 2026-09-16, 6.59.0.0 on 2026-09-09 and 6.58.0.0 on 2026-08-19. The version scheme is four-part, and the README states that the whole platform is released under a single version, so upgrading means moving the BOM rather than reconciling modules that drifted apart.

The cadence change is the main operational cost to plan for. From 1 October 2026, Maven Central receives new releases quarterly while maven.http4k.org keeps the 1-2 week cadence. A build that resolves only from Maven Central will lag the project's actual release rate, which matters if you are waiting on a fix. Pointing at maven.http4k.org is the documented way to stay current, and the README says both channels are supported.

Upgrade cost itself is hard to judge from the README alone. What is visible is a CHANGELOG.md at the repository root, a version.json file, and DISTRIBUTION.md and VERIFYING.md alongside the usual governance and security documents. The CHANGELOG is where you would check whether a given release touches a module you depend on. For regulated environments, the Enterprise tier's SLSA provenance, signed SBOMs and cosign signatures are the supply-chain story, and VERIFYING.md is the document to read if you intend to check artifacts rather than trust the channel.

Editorial conclusion

Adopt http4k when you want HTTP services expressed as plain Kotlin functions with no framework runtime in the middle, and when being able to run the identical handler in a test, in a JDK server and in a GraalVM binary matters. Do not adopt it if you need an opinionated container, dependency injection and a large managed ecosystem out of the box; Spring Boot covers that ground and http4k deliberately does not. Before committing, verify two things: which release channel your build resolves from, given that Maven Central publication moves to a quarterly cadence from 1 October 2026 while maven.http4k.org keeps the 1-2 week cadence, and whether the modules you need live in the Apache-2.0 Community Edition or in the commercially licensed org.http4k.pro group. Then write one handler and mount it with app.asServer(SunHttp(8000)).start() to confirm the model fits how your team thinks.

Frequently asked questions

Official sources

1. http4k/http4k on GitHub
2. Issues
3. Project website
4. README
5. Releases