Hi everybody!

Last year I wrote an introductory post to Http4s and a few months later I started using it in the company I was working for. Results have been very good so far regarding readability in a pure-functional-style, usability, throughput and performance in production environments so I would recommend the use of it.

In this post I want to show you how to create a simple CRUD (Create, Read, Update, Delete) demo, always needed when creating an API. And in this kind of operations you will always need to handle expected errors from the backend and returning the appropriate HTTP Status Code and response. So let’s start!

EDIT: This post has been written in October 2016 using Http4s v0.14.6 for the examples and things have changed quite a lot ever since. For a newer version using Http4s v0.18.x (Cats v1.0.0-RC1) please check out this Giter8 Template, this repo and this blog post about all the updates.

CRUD for users

In this demo we will create a CRUD for an User (username, email and age). We will support the following operations:

Find all the users sorted by username Create a new user: If the username already exists return a descriptive error.

Otherwise return the user with the designated id. Find user by id: Return either the user or a descriptive message indicating user not found. Edit the age of a user by id: Return either a successful code or a descriptive message indicating user not found. Delete user by id: Return either a successful code or a descriptive message indicating user not found.

HTTP Status Code Responses

So far this is the definition of the most common use of a crud with some validations. Let’s see how we define the HTTP Endpoints for all these operations:

GET /users | /users?sort=ASC | /users?sort=DESC Returns a 200 http status code with a list of all the users. POST /users If the username is already in use returns a 409 http status code indicating the duplication.

Otherwise creates the user and returns a 201 http status code and the user with id in the body. GET /users/{id} If the user exists it returns a 200 http status code and the user itself.

Otherwise it returns a 400 http status code indicating user not found. PUT /users/{id} If the user exists it returns a 202 http status code.

Otherwise it returns a 400 http status code indicating user not found. DELETE /users/{id} If the user exists it returns a 204 http status code.

Otherwise it returns a 400 http status code indicating user not found.

OK, show me the code!

We will start by creating the main app running the server, as indicated by the official documentation, it’s recommended to extend the ServerApp trait that will handle the shutdown and clean up of the resources automatically:

package com.gvolpe.http.server import com.gvolpe.http.server.endpoint.UserHttpEndpoint import org.http4s.server.{Server, ServerApp} import org.http4s.server.blaze._ import scalaz.concurrent.Task object HttpApi extends ServerApp { override def server(args: List[String]): Task[Server] = { BlazeBuilder .bindHttp(8080, "localhost") .mountService(UserHttpEndpoint.service) .start } }

By default we use the Blaze server as it is the native backend supported by http4s but it’s also possible to use different servers, however that topic is out of the goal of this post.

Our UserService trait defines the CRUD operations always returning a scalaz.concurrent.Task[A] as shown below:

trait UserService { def save(user: User): Task[Unit] def findAll(sort: UserSorting): Task[List[User]] def find(id: Long): Task[User] def remove(id: Long): Task[Unit] def edit(id: Long, age: Int): Task[Unit] }

We will not care about the implementation of this service because what it matters in this case is the returning types and the possible expected errors that a Task might contain when it runs. However you can take a look at our default implementation on GitHub (link at the end of the post).

In the code shown above the type UserSorting is just an ADT defining two possible values, either Asc or Desc.

Main User HTTP Endpoint

So this is how our UserHttpEndpoint object referenced by the main server app looks like. First of all, we define the codecs available implicitly in the scope of the object. For this purpose we are using the amazing Circe library using automated codec derivation.

implicit def circeJsonDecoder[A](implicit decoder: Decoder[A]) = jsonOf[A] implicit def circeJsonEncoder[A](implicit encoder: Encoder[A]) = jsonEncoderOf[A]

Then we define the main resources of the endpoint as an HttpService that represents a PartialFunction[Request, Task[Response]]:

val service = HttpService { case GET -> Root / "users" : ? SortQueryParamMatcher(sort) => Ok(UserService.findAll(UserSorting.from(sort))) case req @ POST -> Root / "users" => req.decode[UserForm] { userForm => val user = User(Random.nextInt(1000), userForm.username, userForm.email, userForm.age) UserService.save(user).flatMap(_ => Created(s"User with id: ${user.id}")).handleWith(errorHandler) } case GET -> Root / "users" / LongVar(id) => Ok(UserService.find(id)).handleWith(errorHandler) case DELETE -> Root / "users" / LongVar(id) => UserService.remove(id).flatMap(_ => NoContent()).handleWith(errorHandler) case req @ PUT -> Root / "users" / LongVar(id) => req.decode[UserAgeForm] { ageForm => UserService.edit(id, ageForm.age).flatMap(_ => Accepted()).handleWith(errorHandler) } }

In the code shown above we are using a SortQueryParamMatcher and an errorHandler variable that we didn’t see yet, so this is how is defined:

object SortQueryParamMatcher extends OptionalQueryParamDecoderMatcher[String]("sort") private val errorHandler: PartialFunction[Throwable, Task[Response]] = { case UserNotFoundException(id) => BadRequest(s"User with id: $id not found!") case DuplicatedUsernameException(username) => Conflict(s"Username $username already in use!") }

Adding a new validation would be just adding a new case in the partial function, very simple isn’t it?

Final thoughts

As I said at the beginning of this post I totally encourage the use of this powerful library if you like to write pure functional code and at the same time having great performance results. The documentation has improved a lot since the last year so please give it a try and let me know if you would like me to write about any other feature of this library not covered either here or in the official docs.

As always, a demo project for this post is available on GitHub, check it out here!

Until next post!

Gabriel.

PS: I’m currently on a world trip for undetermined amount of time and sometimes with limited connection to Internet so the gaps between posts might be bigger but I’ll try to keep on writing. I suppose I’ll be back in the industry next year at some point… Cheers from India!