Question

I’d like to validate json contains a list of key/values before attempting to marshall into a case class using lift-json. The data might be nested.

For example:

{ 
 "name": "stack",
 "desc": "desc",
 "age": 29,
 "address": {
  "street": "123 elm", 
  "postal_code": 22222,
  "city": "slc",
 }
}

What are ways I can verify this JSON contains values for “name”, “age”, and “address\street”? Assume all other fields are optional.

Sorry if I’m missing something obvious, but I suspect something like this has been solved before.

By the way, anyone try Orderly? https://github.com/nparry/orderly4jvm

Answer 1

As I see it you’ve got a few options:

1. You could use lift-json’s “Low level pull parser API” (search for that phrase on this page) to grab each of the fields you care about. If you haven’t gotten all of the fields you want at the point that you encounter the End token, you toss an exception. If you have of the required field, then create your object.

   Pro: This only parses the JSON once. It’s the highest performing way of using lift-json.

   Con: You’ve created brittle, hand rolled software.

2. You could use lift-json’s JsonAST, which is the normal result of calling its parse method (search for “Parsing JSON” on this page), and then its XPath-like expressions (search for “XPath + HOFs” on this page) to determine if the required fields are present. If they are, create your object by passing the appropriate fields to the constructor.

   Pro: Less hand rolled than #1. Only parses the data one time.

   Con: This isn’t quite as fast as #2.

3. Use the methods from #1 or #2 to determine if the required fields are present. If they are, then use lift-json’s deserialization (look for the “Serialization” heading on this page) to create and object.

   Pro: I’m really stretching here… If you expected much of the data to be bad, you’d be able to determine that before entering the somewhat more heavyweight process of lift-json deserialization

   Con: You’ve parsed the data twice in the case that the data is valid.

4. Just use lift-json’s deserialization (look for the “Serialization” heading on this page). It more or less does what is described in #2, except it uses reflection to figure out which fields are required.

   Pro: This is the most maintainable solution

   Con: It’s slower than #1 and #2.

My recommendation: Unless you absolutely need the best possible performance, use #4. If you really have a need for speed, use #1. One other benefit of using a #1 or a #2 style solution is that they allow you to do odd coercion to the data, such as mapping two alternative field names in JSON to a single field in the scala object.