C2D DirectMethods-Creation-Json payload in the SDK

[jonmikeli]

Hi,

Is there a reason why in the SDK, the payload of the Direct Methods (creation of the Direct Method) can only be JSON?
https://github.com/Azure/azure-iot-sdk-csharp/blob/main/iothub/service/src/DirectMethod/CloudToDeviceMethod.cs

Direct Methods handlers do not require this.
Different development tools like the IoT Explorer allow sending payloads different from JSON.

I was starting to code it and push the PR but, there is maybe a reason. So, before going any further, I prefer to ask the question.

[drwill-ms]

Hi @jonmikeli -

We're talking about it within the team. The (probably) short answer is that when the SDKs were originally built, the authors thought JSON would be the only format someone would care about. I'm sure that is shortsighted.

Can you say more about what format you'd like to be able to send?

Also, what format have you sent over IoT Explorer? I know, for instance, that you can pass JSON primitives, like 123 or [ "abc" ], which isn't a JSON document but is valid JSON.

Thanks,
David

[jonmikeli]

Hi @drwill-ms ,

Thank you for your answer.

We have been sending numeric values or short strings to Direct Methods, through the IoT Explorer.
Use cases:

• update logical/business status and initiate operations
• update telemetry emission rates
  This is how we noticed the difference between the IoT Explorer and the SDK.

There is no problem in sending the appropriate JSON but I was wondering if there was a reason why the calling Direct Methods and the handlers are not designed to process the payload in the same way (main reason for my question, no blocking issue).

Similarly to the authors, at first, I would have thought that JSON could be enough.
From the practical perspective, it is true that sending numeric or string values directly is handy (and optimizes slightly the data flows/processing in some cases).
Maybe, sending hexadecimal or encrypted raw data could be useful too (but just speaking theoretically, I have not been confronted with such needs).

Best,

[drwill-ms]

JSON doesn't mean it must be a JSON object (e.g., { "foo": 4 }. It can even be a JSON primitive type (e.g., 4). So even if you just pass an integer or a string, both of which are JSON primitive types, it is still considered JSON.

As for hexadecimal or encrypted raw data, we haven't had requests from customers for .NET or Java SDKs, although I'd agree it might be useful for someone. If that is a use case for you, please let us know. :)

[kumaakh]

Yes it is certainly useful for sending binary messages to device which are more compact such as CBOR and ProtoBuf