The reason for the contradiction is, that on the (unreleased) BOND Cloud API, these objects will be expanded in the reply, while they are “stubbed” in the Local API. — Other than that, we are maintaining exactly the same logical API between the Local and Cloud.
Perhaps we could make two sets of example responses, one expanded and one stubbed.
Indeed on the backend (Cloud API) it is desirable to have fewer calls, perhaps with larger reply bodies. However, for the Local API, we need to keep the memory usage down, and the maximum reply size is a major driver of memory usage.
That said, if this stubbed Local API design is really a problem, we could make the HTTP replies use Chunked transfers, but it would involve significant development effort that may be better invested in BOND-specific features.
Agreed that a 204 should have no HTTP content! Will check into this.
Actually, as @residualimages guessed, this is not guaranteed. – What’s happening is, the JSON object is stored as a linked-list in RAM, and the JSON library we are using (cJSON) is rendering the output in the same order as is stored in memory. When you reboot, the commands are read from a flash database, the order of which may change during compaction. So, order of the JSON object key:value pairs is totally arbitrary.
Glad you like the openness! We’ll expose everthing we reasonably can…