evaluate the general anatomy of dynatrace APIs

jkleinlercher commented 4 years ago

we need to better understand the general anatomy/behaviour of the dynatrace APIs.

Until now I did not know if successful return codes are always HTTP 204 and if the http method is always PUT, or sometimes POST. Now it seems that every successful return code is HTTP 204. And if we find out in issue #1 that the http method is always PUT with the evaluated ID of the existing object (except if the object doesn't exist, it is a POST), then we can remove the method and success keys in the config json files.

jkleinlercher commented 4 years ago

I will export every config object of my trial account to https://github.com/rockaut/dynatrace-config/tree/master/experiments/config and try to get a better feeling how every API works.

jkleinlercher commented 4 years ago

since issue #1 is implemented for most of the configuration objects I now know that return codes and http method are pretty straight forward, so they don't need to get specified in the json files anymore. I will definitely need to test now every configuration API with the current version of this program to get a better understanding what works and what not. Outcome of this task should be a summary of problems and confusions.

jkleinlercher commented 4 years ago

status of test: done:

all simple APIs are already in the config folder and tested

next steps: all APIs dealing with list items:

v1/alertingProfiles (empty by default)
v1/anomalyDetection/diskEvents (empty by default)
v1/anomalyDetection/metricEvents (some entries already exist)
v1/applicationDetectionRules (empty by default)
v1/autoTags (inludes sample tag entry)
v1/aws/credentials (empty by default)
v1/cloudFoundry/credentials (empty by default)
v1/dashboards (home dashboard entry)
v1/kubernetes/credentials (empty by default)
v1/customMetric/log (empty by default)
v1/maintenanceWindows (empty by default)
v1/managementZones (empty by default)
v1/notifications (empty by default)
v1/service/customServices/{technology} (empty by default)
v1/service/ibmMQTracing/imsEntryQueue (empty by default)
v1/service/ibmMQTracing/queueManager (empty by default)
v1/service/requestAttributes (empty by default)
v1/service/requestNaming (empty by default)

more complex APIs:

v1/symfiles (Mobile Deobfuscation and Symbolication), needs an applicationId
v1/plugins
v1/service/detectionRules/FULL_WEB_REQUEST (empty by default) - not sure what this API does
v1/service/detectionRules/FULL_WEB_SERVICE (empty by default) - not sure what this API does
v1/service/detectionRules/OPAQUE_AND_EXTERNAL_WEB_REQUEST (empty by default) - not sure what this API does
v1/applications/web (empty by default)

jkleinlercher commented 4 years ago

all new api tests go to feature/#2 branch

rockaut / dynatrace-config

evaluate the general anatomy of dynatrace APIs #2