Least amount of work in order to get this running "correctly" is probably getting an ActiveX library to call through AutoLisp. Perhaps look at the libraries listed at the botom of this page:
http://json.org/In particular those for VisualBasic. I think the VB-JSON library is intended for VB6 ... so it should be an ActiveX library.
Alternatively rolling one from DotNet and opening such as a lispfunction shouldn't be a huge load of work, definitely less than trying to implement it direct in AutoLisp - especially if you want all the nuances possible in JSon.
This sort of thing is why I'd discourage such formats if at all possible. They'd only be useful if you need the data in some other program which can only read/write JSon / XML. If you simply want to save/send data which you again read/modify/save from another AutoLisp, then everything XML/JSon/ProtoBuf/whatever other serialization can do can be done using normal S-Expressions (i.e. normal Lisp syntax which you can get using the read/write built-in functions).
Actually if you're going to have to re-implement it you're wasting your time. Even if you "have" to do so, I'd avoid XML/JSon (or in fact any human-readable and especially human-modifyable format). That's because most of your time will be spent on trying to catch slight errors someone made while writing it. And if you just use this for communication between programs, then why a human-readable format at all? Much more efficient is any sort of native format, be that binary (like ProtoBuf) or same as system (like S-Expressions). Binary would even have the advantage of using the least space - especially of concern when sending such data over networks (else you're doing something similar to sending a DWG file as a DXF file, just so it can be converted back at the other end to DWG again).
in the simplest cases just like yours there is no need to parse json
(setq str "{\"attributes\": {\"color\": \"ffffaa00\",\"layer\": \"LAY012\",\"areaval\": 1351.014,},\"geometry\": {\"rings\": [[[5651.534,8026.656][5653.917,8083.191]]]}}")
(read (vl-string-translate "[]{}:," "()() " str))
Very good idea ... though it's not exactly the same thing. E.g. the attributes object will become just a list of values, with attrib name followed by value. More correctly this should become an association list instead. And that sort of "where do quotes go" story is exactly the sort of problems to run into when re-implementing yet another JSON parser (it's actually a lot worse with XML as you need to also then parse open / close tags, meaning even spelling errors become an issue).
