Move IoT Hub to operation builder pattern #960
Conversation
| .get_configuration(configuration_id) | ||
| .into_future() | ||
| .await?; | ||
| let configuration: Configuration = configuration.try_into()?; |
There was a problem hiding this comment.
This is a bit of a shame that we are now returning an unstructured type.
| @@ -139,6 +140,7 @@ macro_rules! operation { | |||
| ) => { | |||
| azure_core::__private::paste! { | |||
| #[derive(Debug, Clone)] | |||
| $(#[$outer])* | |||
| configuration_id: String, | ||
| priority: u64, | ||
| target_condition: String, | ||
| etag: Option<String>, |
There was a problem hiding this comment.
Instead of exposing two operations, we could do what the Python SDK does, which is to have a single create_or_update function, and provide the optional parameter if_match.
if_match
ETag of the IoT Hub. Do not specify for creating a brand new IoT Hub. Required to update an existing IoT Hub.
There was a problem hiding this comment.
This could be done across the crate.
There was a problem hiding this comment.
| /// The DeleteConfigurationBuilder is used to construct a request to delete a configuration. | ||
| DeleteConfiguration, | ||
| client: ServiceClient, | ||
| if_match: String, |
There was a problem hiding this comment.
Similar with above, we should standardize on etag vs if_match. Additionally, this should be optional.
https://docs.microsoft.com/en-us/rest/api/iothub/service/configuration/delete#request-headers
This changed the user interface a little bit, and made it a tiny bit worse IMO, but I think we can easily regain that usability in a follow up.
NOTE: This does not update IoT Hub to use the pipeline yet. That will be a follow-up PR.
This is part of the work for #802