[erlang-questions] Erlang APIs and JSON

[Erik Søe Sørensen]

When I ran into the "how to treat JSON input?" question some time ago, this
was my answer:
<self-plug>
  https://github.com/eriksoe/valijate
(I've been tempted to mention it several times recently when JSON was
discussed on this list. This time I give in.)

It's a tool for validating the JSON, *and* turn it into a form suitable for
further use in Erlang.
The form of the output follows the form of the typespec given to the
validator:

    % A JSON value:

    > S = "{\"title\": \"Hogwarts, a History\",
\"authors\":[\"Bathilda Bagshot\"], "++
          " \"price\": 3.99, \"available\": true}".

    % A type/format specification:

    > T = {object, [{<<"authors">>, {array,string}}, {<<"title">>, string},
                    {<<"available">>, boolean}, {<<"price">>, number}]}.

    % Parse, validate and convert:

    > J = mochijson2:decode(S).
    > {ok,{Authors,Title,Available,Price}} =
          valijate:validate(J,T).

    => {ok,{[<<"Bathilda Bagshot">>], <<"Hogwarts, a History">>,true,3.99}}

Valijate works with the data structures used by mochijson2 and ejson.
I've tried to make it flexible (with an expressive typespec language), and
with decent error reporting:

    > S2 = "{\"title\": \"Hogwarts, a History\", \"authors\":[\"Bathilda
Bagshot\", 12], "++
          " \"price\": 3.99, \"available\": true}".
    > E = valijate:validate(mochijson2:decode(S2),T).
    => {validation_error,[<<"authors">>,1],
                  {wrong_type,12,number,string}}

    > valijate:error_to_english(E).
    => "At path .authors[1] : Value 12 has type number, but string was
expected"

When it turned out that I wanted to do similar validation of configuration
values from Erlang's .config files, I even added support for validation of
Erlang terms as well.
</self-plug>

If valijate turns out to be useful (or just nearly so) to anyone else,
please tell me - then I could polish it up and do a proper [ANN] of it...

/Erik



2013/8/30 Garrett Smith <g@REDACTED>

> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130831/90a6628c/attachment.htm>