Add Iot Hub API categories to design doc #11649
Conversation
|
These are good points Tim. |
There was a problem hiding this comment.
This looks like a good starting point!
The existing API surface doc, for reference: https://github.com/Azure/iot-sdks-internals/blob/master/sdk_design_docs/CSharp/Microsoft.Azure.Devices.md
| ``` | ||
| </details> | ||
|
|
||
| <details><summary><b>Registry</b></summary> |
There was a problem hiding this comment.
A note here, stating that these relate to IoT Hub identity registry operation, would give some additional context.
|
|
||
| [Response](https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/core/Azure.Core/src/Response.cs): Contains the raw HTTP response details | ||
| <details><summary><b>Method</b></summary> |
There was a problem hiding this comment.
same: note - Invoke direct method on a device
|
|
||
| [Page\<T>](https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/core/Azure.Core/src/Page.cs): A single page within a Pageable. Should not be exposed to the user, since we strive to abstract out the pagination | ||
| <details><summary><b>Twin</b></summary> |
There was a problem hiding this comment.
note - Device and module twin operations
Microsoft.OperationalInsights: Updating property name + Adding a new resource (Azure#11649) * Updating property name. * example update. * Adding force cmk to workspace. * Adding default error response. * Removing redundant examples. * adding workspace capping to example per code review request. * Per review request. Co-authored-by: Dudi Likvornik <[email protected]>
A few notable things I discovered with this swagger:
No sign of file upload notification receiving. This was an AMQP API before, and I was expecting to see it here. Same issue with sending cloud to device messages. They did create an HTTP API for handling cloud to device feedback messages, which used to be AMQP.
There are two sets of Jobs APIs. I suspect the service folks would prefer we only expose the v2 APIs, but we should talk to them about this.
There are a couple of fault injection APIs. From my understanding, this aren't meant to be used by customers, so we should not expose them in our SDK
There are also digital twin APIs present in the swagger, but since we are refreshing them, I didn't include them here