Have you thought about data integrity? JSON is a high-level data format expecting flawless transport layer under it, any corruption totally wrecks havoc.
UART seems like very simple interface for such ASCII-based protocol, just JSON over UART, easy to write specification for: "send JSON over UART", job done. But really, you should consider adding some kind of checksum, and then this will mean another layer below the JSON. It can be very simple, like CRC16 over the JSON data after the last closing }, but still something the end-user of the protocol needs to consider, making it a tad less approachable. Especially when nasty things like CR-LF conversions are happening, my biggest pet peeve in poorly though out (nearly all!!) ASCII-based protocols.
Regarding that, people like nctnico say, "use ASCII protocol because it's easy to use and debug", yet I think I have never seen an actual product (besides ones by myself) which Just Work out of box whether you feed it CR, LF, CRLF or LFCR. In fact, just finding a serial communication program for linux and/or Windows, where you can configure the line feed conversions (so that the feature is actually fully implemented and tested, and works), is a real struggle. Last time I spend some 2-3 hours finally finding picocom and compiling the latest version from sources, because the version the distro offered couldn't really do this simple thing. I'm baffled by this constantly reoccurring struggle, because it's quite easy to get right; either do not use meaningful whitespace at all (for example, use ; to finish commands), but if you do want to use the enter/return key as a delimiter, accept both CR and LF as if they were exactly the same symbol, and make sure the parser doesn't go haywire with an empty message (i.e., repeated CR/LF delimiter).