In scala-land, I've got experience from Scalatra, http4s and Play framework. We've recently migrated a large Scala project from Scalatra to http4s. I would not recommend using the current 2.x version of Scalatra. The biggest issue I've got with it is it's lack of type-safety. Each REST-endpoint in Scalatra is basically a function from Request to Any. So you can return anything and cross your fingers it works runtime (see e.g. https://github.com/scalatra/scalatra/issues/534). I believe many of the core Scalatra-contributors are nowaday much more active in development of the http4s (see https://github.com/scalatra/scalatra/graphs/contributors vs https://github.com/http4s/http4s/graphs/contributors).

I really like the design of http4s; services compose really nicely -- each service/server is just a partial function from Request to Response. It utilizes Scalaz Tasks for asynchronous opeartions / streaming. On the other hand, I would not consider http4s very mature yet. We've encountered some issues during refactoring from Scalatra to http4s. Also, they offer support for both Servlet- and Blaze NIO -servers, but I've had the feeling that Servlet-support feels a bit like second-class citizen. Maybe not so thoroughly tested (I'm just spitballing here)? But still.. I like it and based on current experience would not advice against using it. Also, I've had great help from their Gitter-channel. :)

Play framework, is nowadays pretty mature. I've used it in multiple projects, and love that nowadays it's sbt compatible (just declare the dependencies) -- I think in the past you had to download a separate distribution for using it.

I think http4s and Play are both excellent choices. Play feels a bit bloatish and maybe opionated compared to http4s, but on the other you've got everything ready (play-ws, play-json, play-twirl etc.). Once http4s gets a bit more mature, I believe it'll be awesome! :)

P.S. With http4s my current recommendation would be: Argonaut for JSON, and Slick for RDMS-support (Postgres all the way).