[erlang-questions] Erlang APIs and JSON

[Garrett Smith]

Hi Mark,

On Fri, Aug 30, 2013 at 3:22 PM, Mark Allen <mallen@REDACTED> wrote:
> I am wondering if anyone has opinions on how to deserialize JSON HTTP request bodies into Erlang terms.  Tuple wrapped proplists seems to be how it comes back from mochijson2:decode() and jiffy:decode().  Erlson returns orddicts hidden in a record-like syntax via a parse-transform.

It's initially odd, but {Proplist} has emerged as a standard-ish
representation of a JSON associative array in Erlang. It's better IMO
than dealing with the "what is this list - a string or an array?"
question.

> Does anyone further deserialize proplist(s) into records?  Why or why not?

All the time. If your data prefers to be represented as records, do
that -- and make the interface to JSON do the work once and be done
with it. This is similar to pulling data out of a database -- every
driver will have its own (weird) representation. I like to get it into
the application-native format as quickly as possible, apply validation
as early as possible.

Alternatively, if your JSON is acting more as a lookup table -- strip
off the one-tuple and use proplists:get_value - it's *very* efficient
with small lists (based on rough measurements, < 200 items).

> What are the best (or even suggested) practices for dealing with JSON data?

I like the "make it work" and then "make it work better only as
needed" best practice :)

JSON and Erlang terms are similar enough that naively one might expect
there to be zero conversion cost (both in time and logical
complexity). I think if you give up on seamlessness and treat JSON as
an arbitrarily complex format -- and each driver as arbitrarily
inconvenient -- you just wrap the messiness and get on with it.

> This might be a FAQ. If so, kindly point me toward the Fine Reading Material.

Just my two cents. If you end up publishing this and generating Google
ad revenue, I'd appreciate a beer.

Garrett