HTTP REST API's in Kotlin?

Is there a particular http back-end that is favored in the Kotlin community?

I want something lite weight that will enable me to create a json rest api using Kotlin.

Background:
I have a legacy json rest api written in java. The json part is Jackson. The http part is JSP. Just the outer edge is jsp. It is 90% java.

What I have now mostly looks like this:

<%
int week = Http.paramIntRequired(request,"w");
int year = Http.paramIntRequired(request,"y1);
ParDto dto = ParService.par(week,year);
out.print(dto.toJson());    
%>

This all runs on Tomcat. But I am starting to move my backend code to Kotlin. The ParService and ParDto are now written in Kotlin.

To be honest, I was surprised at how easy it was to call Kotlin from java like this. I have java calling kotlin and kotlin calling java. So painless!!

But it would be nice if this last 5 yards (the jsp part) could be written in kotlin.

I was thinking of porting the http part to something more modern. I have used Spark framework (in java) and liked it. Also, vert.x looks interesting.

So what are people in the kotlin community using to create their http backends?

We use TomEE 7 (Tomcat + Java EE 7) for all of our REST APIs.

I find JAX-RS a great REST framework, in addition to using a few other parts of Java EE (CDI, JAX-B, BeanVal, etc).

We started using the (little known?) AsyncResponse feature of JAX-RS to go “reactive”, in combination with Akka.

Our stack now looks like below. I realize it’s way more than you asked in your question, but I guess to give a full picture…

  • Kotlin (1.1.0-rc-91)
  • TomEE 7 (7.0.2), which uses johnzon under the covers for JSON marshalling
  • Akka 2.12
  • ElasticSearch
  • HazelCast
  • DB2/PostgreSQL 9.4 for RDBM, and looking into ScyllaDB for NoSQL (c* drop-in)
  • kaconf (kick-ass config)
  • tinylog
  • orika mapper (DAL/DTO to API models)
  • ZooKeeper + Kafka
  • Docker Engine Swarm 1.13 (as of ~2 weeks ago, heading to production in ~2-4 more)
  • Kubernetes as our final state for Docker orchestration (Swarm is too bleeding edge)
  • nginx for all things routing, proxying
  • Investigating Mashape Kong for API gateway (we use openresty with some lua modules for http signature auth, so good fit)
  • Jenkins currently, Concourse being stood up for Docker build+deploy

No particular web back-end library/framework/toolkit is favoured by the Kotlin community. Perception wise there are slightly more Kotlin developers going for Spring Boot followed by Vert.x. Both back-end systems have very strong Kotlin developer interest and have some Kotlin support (Vert.x provides the best Kotlin support at the moment). Presumably @stokemasterjack is after a back-end system with a reactive style API, official Kotlin support, and a high level concurrency model in which case Vert.x would be an excellent choice.

Vert.x’s API style is a very natural fit (lambdas instead of annotations for explicit APIs which ARE NOT MAGICAL) with the API style commonly found in many Kotlin libraries/frameworks (including the Kotlin standard library). Can already use Vert.x 3.3 with Kotlin via the Java API (works very well), but keep in mind the Kotlin support (the Kotlin API) is in Vert.x 3.4 which is currently under development. A pragmatic strategy to go for is to migrate to Vert.x 3.3 and migrate to Vert.x 3.4 when it is stable (changes between the versions are likely to be small).

Already seen that @stokemasterjack is planning to move from JSP to React which is going to make it much easier to move to the modern Java web frameworks/libraries/toolkits, which in general don’t support Servlets and only use an embedded web server like Netty.

This Spring Boot presentation provides a basic idea of how Kotlin JS is progressing even though the information is a bit dated (covers Kotlin 1.0 instead of 1.1).

Check out ratpack. I built a kotlin dsl for it that makes building apis simple.

We’re using apache spark to good effect.

Updating a reply to this thread to say I am checking out hexagon, http4k and jooby.

jooby looks like my top pick so far. It uses netty, jetty, or under (I’m trying out undertow for best performance).

A stupid simple hello-world type test is giving me ~20k/sec vs 10k/sec compared to TomEE (non-servlet faster).

I’m starting to see the reason why there are religious debates about servlet containers being dead. Undertow starts 8 http threads and hands the work off to a worker thread pool instead of a thread-per-request.