Closed jkleinlercher closed 4 years ago
it seems, if the configuration object we need to change is an item in a list, we would need to
However, not all configuration objects are list items (like tags, alerting-profiles, dashboards, kubernetes credentials, ...), some are also just base configurations (services anomaly detection, https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/configuration-api/anomaly-detection-api/anomaly-detection-api-services/)
most of the list objects can be created or updated the same way. there are some which are confusing: "v1/dashboards": name identifier seems to be nested, currently not supported "v1/service/customServices": customServices is split into different technologies, not supported right now "v1/service/ibmMQTracing/imsEntryQueue": document says name but in configuration payload there is no name
Nevertheless I think we can close this task for now. I definitely need to test every use case now to get a better understand what works and what not.
changing configuration with PUT method is idempotent (like changing service anomaly detection with https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/configuration-api/anomaly-detection-api/anomaly-detection-api-services/put-config/). however, creating new objects with a POST method is not idempotent (like creating a new tag https://www.dynatrace.com/support/help/extend-dynatrace/dynatrace-api/configuration-api/automatically-applied-tags-api/post-auto-tag/)
since we need a general way to describe the desired state we either check if the object already exists in our tool or we discuss the API with dynatrace.