It seems a bit like a toss-up to me ... Taking examples from your landing page I can see some where there is less typing in JSON and some where there is more. F

It seems a bit like a toss-up to me ... Taking examples from your landing page I can see some where there is less typing in JSON and some where there is more. For example, the book one - I counted the equivalent JSON and they were 128 non-whitespace characters vs. 127 non-whitespace characters. Practically, at least for my editor, I had to type less for JSON because every paired character automatically inserts the closing equivalent. This is likely to work across a wide range of editors from the browser console to whatever else fringe text input field. Once you account for paired characters JSON wins at 114 chars. Of course if you had editor support for XENON it could also automatically insert some of the control characters, at the very least all of the > and the <$>, which brings XENON to 117 chars typed. Anyway, I think you probably would've gotten a less strong response from people here if you had less absolute statements on the site ("better alternative", "the best way") - certainly there are going to be use-cases where this excels, but I can also see how the average simple REST API would be very unlikely to benefit from this, and the extra features may in fact expose it to more risk (e.g. the graph support, look at YAML and the CVEs it has caused over the years)