<div dir="ltr"><div>When I ran into the "how to treat JSON input?" question some time ago, this was my answer:<br></div><self-plug><br><div> <a href="https://github.com/eriksoe/valijate">https://github.com/eriksoe/valijate</a><br>
(I've been tempted to mention it several times recently when JSON was discussed on this list. This time I give in.)<br></div><div><br></div><div>It's a tool for validating the JSON, *and* turn it into a form suitable for further use in Erlang.<br>
</div><div>The form of the output follows the form of the typespec given to the validator:<br><pre> % A JSON value:<br></pre><pre> > S = "{\"title\": \"Hogwarts, a History\", \"authors\":[\"Bathilda Bagshot\"], "++
" \"price\": 3.99, \"available\": true}".<br></pre><pre> % A type/format specification:<br></pre><pre> > T = {object, [{<<"authors">>, {array,string}}, {<<"title">>, string},
{<<"available">>, boolean}, {<<"price">>, number}]}.<br></pre><pre> % Parse, validate and convert:<br></pre><pre> > J = mochijson2:decode(S).
> {ok,{Authors,Title,Available,Price}} =<br> valijate:validate(J,T).<br>
=> {ok,{[<<"Bathilda Bagshot">>], <<"Hogwarts, a History">>,true,3.99}}<br></pre>Valijate works with the data structures used by mochijson2 and ejson.<br></div><div>I've tried to make it flexible (with an expressive typespec language), and with decent error reporting:<br>
<br> > S2 = "{\"title\": \"Hogwarts, a History\", \"authors\":[\"Bathilda Bagshot\", 12], "++<br> " \"price\": 3.99, \"available\": true}".<br>
> E = valijate:validate(mochijson2:decode(S2),T).<br> => {validation_error,[<<"authors">>,1],<br> {wrong_type,12,number,string}}<br><br> > valijate:error_to_english(E).<br>
=> "At path .authors[1] : Value 12 has type number, but string was expected"<br></div><div><br></div><div>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.<br>
</self-plug><br><br></div><div>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...<br><br></div><div>/Erik<br></div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/30 Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Mark,<br>
<div class="im"><br>
On Fri, Aug 30, 2013 at 3:22 PM, Mark Allen <<a href="mailto:mallen@alertlogic.com">mallen@alertlogic.com</a>> wrote:<br>
> 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.<br>
<br>
</div>It's initially odd, but {Proplist} has emerged as a standard-ish<br>
representation of a JSON associative array in Erlang. It's better IMO<br>
than dealing with the "what is this list - a string or an array?"<br>
question.<br>
<div class="im"><br>
> Does anyone further deserialize proplist(s) into records? Why or why not?<br>
<br>
</div>All the time. If your data prefers to be represented as records, do<br>
that -- and make the interface to JSON do the work once and be done<br>
with it. This is similar to pulling data out of a database -- every<br>
driver will have its own (weird) representation. I like to get it into<br>
the application-native format as quickly as possible, apply validation<br>
as early as possible.<br>
<br>
Alternatively, if your JSON is acting more as a lookup table -- strip<br>
off the one-tuple and use proplists:get_value - it's *very* efficient<br>
with small lists (based on rough measurements, < 200 items).<br>
<div class="im"><br>
> What are the best (or even suggested) practices for dealing with JSON data?<br>
<br>
</div>I like the "make it work" and then "make it work better only as<br>
needed" best practice :)<br>
<br>
JSON and Erlang terms are similar enough that naively one might expect<br>
there to be zero conversion cost (both in time and logical<br>
complexity). I think if you give up on seamlessness and treat JSON as<br>
an arbitrarily complex format -- and each driver as arbitrarily<br>
inconvenient -- you just wrap the messiness and get on with it.<br>
<div class="im"><br>
> This might be a FAQ. If so, kindly point me toward the Fine Reading Material.<br>
<br>
</div>Just my two cents. If you end up publishing this and generating Google<br>
ad revenue, I'd appreciate a beer.<br>
<span class="HOEnZb"><font color="#888888"><br>
Garrett<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>