Monthly Archives: May 2016

No REST for the Weary – Unless you’re using Akka HTTP RESTful Framework

So yeah the title is a bit of a stretch.  How to work REST into a catchy title wasn’t so easy.  According to,   “There is no rest for the weary”, the idiom “Even people who are worn-out must continue to work. (Describes a situation in which a tired person has to do more work.)”

OK, that’s not too bad.  There are a lot of RESTful frameworks out there for many languages.  There even a fair amount for Scala with the Play framework probably being the most popular.  I have personally worked with Play, Spray, and Akka HTTP.  Fitting that idiom into the theme of this post is that some RESTful frameworks are easier to work with than others.

My experience with Akka HTTP came from my previous employer in which we started working with Play, then moved to Spray, and then finally to Akka HTTP.  Akka HTTP is easy in the sense  that it takes very little code to get a RESTful service up and running.  This is what I like most about the framework in that is stays out of your way.  The framework itself involves creating a boot class, a service layer, response marshaller layer, and protocols for serializing and deserializing domain objects to and from JSON, the framework requires little else from the developer, other than the business logic and persistence layer.  At my previous company we strived for these architectural layers.

So Akka HTTP differs from Play in that it is much more lightweight.  There is no front end templating or tightly coupled JSON library.  Akka HTTP is perfect if you are just creating RESFTful microservices.  My impression with Akka HTTP is that it’s a “take what you need” rather than a “get everything including the kitchen sink” approach.  With Akka HTTP, you can chose the JSON library of your choice, Play, Spray, etc.  Akka HTTP also provides a nice DSL for defining your RESTful routes.  I will say that Play’s routes file is super easy and nice but Akka HTTP is almost as easy.

Akka HTTP also provides a nice HTTP client for interfacing with other services.  The one surprise that it doesn’t have configurations for timeouts but with Scala and Futures that is easily handled with an abstraction.

Another nice addition to make Akka HTTP a little more expressive is to use a functional library like Cats.  With Cats and some additional abstractions you can create some very expressive code.  For instance if I have a function that calls out to an external RESTful service, I can define the signature for that function so that I know that in the “Future”, I can expect some  “ClientError” “Or” some type of “HTTPResponse”.

In any event I’ve created a simple sample Akka HTTP service.  You can find the the source code here.  A very simple, sample, Akka HTTP RESTful service.