JSON in Play Framework - Techniques For Making Compatible Mappings

I’ll show 2 slightly advanced techniques for working with JSON in Play Framework (play-json) that are useful especially when you need to control the mappings yourself. For example when you have to make sure that your API is compatible with existing applications. The examples are based on my project Game Arena (which is in very early stages of development)

One suggestion, before we start, take a look at Play Framework JSON documentation which is truly quite comprehensive and provides a very good introduction to JSON usage in Play.

Even in a very simple project I managed to use few methods for JSON parsing and this post is primary written as a way for me to show how you can work with play-json in the context of Scala case classes.

JSON in Play Framework

Play comes with it’s own JSON parsing library called play-json. Even though it’s sources (github) are in the same repository as the framework itself, it’s published to the Maven repository so you can reuse this knowledge and library in the non-Play projects. Whether or not it’s a good idea is out of the scope for today.

Working With play-json - Basics

I usually put all my JSON mappings into separate Trait. In my case JsonMarshalling and then I extend it in all my Controllers, like that:

@Singleton
class DeckController @Inject() extends Controller with JsonMarshalling {
  def shuffled = Action {
    Ok(Json.toJson(Deck.fullDeck.shuffle))
  }
}

This allows for a very clear separation of concerns, case classes are and don’t have to be aware of their mappings. What’s more I could also provide different JSON mappings in different traits (for example to support multiple API versions).

Case classes

The simplest use case for JSON mapping are case classes (this is true for almost all Scala JSON libraries), in case of play-json you can use a macro to provide mapping for you. For case classes it’s enough to write:

case class User(id: Int, name: String)

implicit val userFormat = Json.format[User]

This will provide mapping to and from JSON. This use case is quite obvious. We automatically will map all fields from a case class to a JSON object. The fields will be called exactly the same.

This is how sample User looks when mapped to JSON:

{
  "id": "1337",
  "name": "Wojtek"
}

Play-json: Slightly Advanced Techniques

Case classes with custom mapping

In case of my project there is a (small) problem. I’m designing my API to be fully compatible with the existing applications, which already use defined field names for all JSON properties. I want to keep using Scala name conventions in my case classes, but for the JSON format I want to follow what is required.

This means that I have to write custom mapping function, from object to JSON, those functions are called Writes[T].

This is an example:

GameState class declaration

case class GameState(
  tournamentId: String,
  gameId: String,
  round: Int,
  betIndex: Int,
  smallBlind: Int,
  currentBuyIn: Int,
  pot: Int,
  minimumRaise: Int,
  dealer: Int,
  orbits: Int,
  inAction: Int,
  players: List[Player],
  communityCards: List[Card]
)

As you can see, I’m able to follow Scala naming conventions here.

Now, the JSON formatting:

implicit val gameStateWrites = new Writes[GameState] {
    def writes(g: GameState) = Json.obj(
      "tournament_id" -> g.tournamentId,
      "game_id" -> g.gameId,
      "round" -> g.round,
      "bet_index" -> g.betIndex,
      "small_blind" -> g.smallBlind,
      "current_buy_in" -> g.currentBuyIn,
      "pot" -> g.pot,
      "minimum_raise" -> g.minimumRaise,
      "dealer" -> g.dealer,
      "orbits" -> g.orbits,
      "in_action" -> g.inAction,
      "players" -> g.players, //intellij complains here, but it's correct and project compiles OK
      "community_cards" -> g.communityCards
    )
  }

This is a longer snippet and let’s more closely. My writes function maps GameState to JsObject. JsObject is basically a mapping from String to JsValue (which can also contain additional JsObjects). This allows me to change output style from Scala’s camel case format to underscore. It’s actually very simple 1 to 1 mapping, but it’s good technique to use when you want to rename field names when outputting JSON.

If you are interested in having all that work done by a library, take a look at play-json-naming (In case API you are communicating with is requiring snake case formatting)

Mapping Case Classes as JsValues

Consider following snippet and case class at the end:

sealed abstract class Suit
case object Clubs extends Suit
case object Spades extends Suit
case object Hearts extends Suit
case object Diamonds extends Suit

sealed abstract class Rank
case object Two extends Rank 
case object Three extends Rank
...

case class Card(rank: Rank, suit: Suit)

The problem is that if we were using default mapping for case classes in case of Card class we would end up with output like this:

{
  "suit": {
    "suit": "Spades"
  },
  "rank": {
    "rank": "Ace"
  }
}

This is not very convenient because our expected format is following one:

{
  "rank": "Ace",
  "suit": "Spades"
}

The first one is why we want to write a custom writes function (I’ll show how this can be done for Suits, and Ranks are done very similarly):

implicit val suitFormat = new Format[Suit] {
    def writes(s: Suit) = JsString(s.toString)

    def reads(json: JsValue) = json match {
      case JsNull => JsError()
      case _ => JsSuccess(Suit(json.as[String]))
    }
  }

This custom writes function makes a mapping from Suit to JsString (line 2). It prevents additional layer of wrapping into objects (simply said, it prevents from adding additional brackets)

Note: I have shown an example how you might want to do this yourself, but in the real project a play-json-extensions library is probably a better choice.

Summary and Followup

I was able to show two play-json techniques that are very useful when dealing with APIs where you need to keep compatibility and cannot rely on default JSON mappings in Play Framework

The followup to this post is here - I show how to remove the code I wrote manually and replace it with 2 clever libraries (thanks to Mikołaj Wielocha for suggesting this approach)

BTW. Did you know that I’m available for hire?