JSON has become a popular inter-process communication (IPC) data interchange format for a variety of computer languages. It is important to understand that JSON is not a protocol, but an encoding format. JSON enables structured data to be serialized into a text format, which is then sent over the wire to the receiving end.
Most IoT protocols utilize TCP/IP as the transport mechanism. TCP/IP is a stream based protocol which does not include any framing information when used for sending messages across the wire. IoT protocols add framing information on top of TCP/IP when transmitting data, making it easy to send packets across the wire. For example, the WebSocket protocol add a size header to the data, and a WebSocket stack provides a packet based API for the application designer using the stack. Pub/Sub protocols, such as MQTT and SMQ, also provide a packet based API.
Since IoT protocols provide a packet based API, any JSON encoder/decoder can be used for serializing and deserializing structured data sent across the wire. However, in some cases an IoT protocol is overkill may add unnecessary memory and processing overhead. An IoT product designer may select to directly use TCP/IP as the transport layer for sending structured data across the wire. A standard JSON encoder/decoder cannot be used when using a non-frame based transport layer.
Our open source JSON library is designed such that it can be used for serializing and deserializing structured data directly on a non-frame based data stream such as TCP/IP. By eliminating the IoT protocol and directly using TCP/IP, the code size can be as small as 3Kb ROM for a combined TCP/IP stack and the JSON library (the uIP TCP/IP stack is only 2.1Kb).
Our open source JSON parser is designed to parse data on a non-frame based stream and can correctly parse JSON packets as they trickle in on a raw data stream.
Unlike protocols based on Remote Procedure Calls (RPC), such as HTTP and CoAP, structured data can be sent asynchronously in both directions at any time. This is in stark contrast to HTTP/REST based applications, which require polling for updates. Polling for updates is specifically inefficient when security and encryption are required. To understand why this is such a bad idea, read The scalability problem with using HTTPS/REST for IoT tutorial.
Security can easily be added by using a TLS (SSL) protocol stack. The TLS layer is added in between the JSON encoder/decoder and the TCP/IP stack. Adding security increases the code size, and the size added depends on the TLS stack being used. With SharkSSL, it's possible to limit this code size to just below 20Kb.
If you are interested in building network programs in C/C++ that sends structured data across a raw TCP/IP connection, read the detailed explanation on how to use our JSON encoder/decoder. See the JSON encoder/decoder documentation for details.
For a quick, visual comparison of the two, check out our "too long; didn't read" chart:
|Not supported||Core feature|
|Moderate to large for micro controllers||Minimal overhead per TCP-JSON message|
The following figure is from the HTTPS/REST tutorial and shows why polling using REST is not recommended and why using a persistent socket connection is preferred for IoT communication.
As you see from figure 1, what appears from a higher level perspective as a single HTTPS request/response is actually a set of several messages sent on the wire. This imposes a problem in HTTPS based systems that require data sent from the server to the device client since such systems require that the client polls the server for updates. The more frequent the polls, the more load placed on the server. As an example, assume we design a remote control system for opening and closing garage doors. Continue reading...