PRO TIP - Global request naming for REST services

[Julius_Loman]

Dynatrace does a pretty good job at request naming for common frameworks. Unfortunately, for some generic REST services, it may require request naming rules or URL cleanup rules, so requests are properly identified.

For example if your requests have names in Dynatrace such as:

• /api/v1/client/123/data
• /customers/812345/shopping-cart

instead of

• /api/v1/client/[ID]/data
• /customers/[ID]/shopping-cart

then you probably know you need to use the request naming rules. The request naming rules can be defined at a particular service. However, if you have many different request URL patterns, it's not efficient to define a rule for each one. There are even more challenges if you need to define such patterns on many services across multiple Dynatrace environments.

In such cases, it's worth considering Request naming rules API and defining a pattern to remove the numbers in requests names.

For the example from above to remove a number from an URL, we need to extract the prefix and postfix. Let's use regular expressions for that:

Prefix extraction pattern	^(.*?/)\d+
Postfix extraction pattern	/\d++(/[^/]*+)$
Condition pattern	/\d++

So our rule will be applied only if the Request URL matches the condition - a forward slash followed by a sequence of numbers. Additionally, we want to define a scope for this rule to apply. This can be accomplished for example by using tags or management zones in the conditions as well as other conditions.

In our case, the request naming rule payload for the API will look like the example below and it will be applied to a set of services tagged by the tag "REST Cleanup". Since this is a JSON payload, the regex patterns must be correctly escaped:

{
 "conditions": [
  {
   "attribute": "WEBREQUEST_URL_PATH",
   "comparisonInfo": {
    "caseSensitive": false,
    "comparison": "REGEX_MATCHES",
    "negate": false,
    "type": "STRING",
    "value": "/\\d++",
    "values": null
   }
  },
  {
   "attribute": "SERVICE_TAG",
   "comparisonInfo": {
    "comparison": "TAG_KEY_EQUALS",
    "negate": false,
    "type": "TAG",
    "value": {
     "context": "CONTEXTLESS",
     "key": "REST Cleanup"
    },
    "values": null
   }
  }
 ],
 "enabled": true,
 "order": "REST 10",
 "managementZones": [],
 "metadata": {
  "clusterVersion": "1.220.96.20210701-171424",
  "configurationVersions": [
   0
  ]
 },
 "namingPattern": "{prefix}[ID]{postfix}",
 "placeholders": [
  {
   "aggregation": null,
   "attribute": "WEBREQUEST_URL_PATH",   
   "delimiterOrRegex": "^(.*?/)\\d+",
   "endDelimiter": null,
   "kind": "REGEX_EXTRACTION",
   "name": "prefix",
   "normalization": "ORIGINAL",
   "requestAttribute": null,
   "source": null,
   "useFromChildCalls": false
  },
  {
   "aggregation": null,
   "attribute": "WEBREQUEST_URL_PATH",
   "delimiterOrRegex": "\/\\d++(\/[^\/]*+)$",
   "endDelimiter": null,
   "kind": "REGEX_EXTRACTION",
   "name": "postfix",
   "normalization": "ORIGINAL",
   "requestAttribute": null,
   "source": null,
   "useFromChildCalls": false
  }
 ]
}

After this rule is applied using the Request naming rules API you can see it also on your service in the Request naming settings section :

Now any future request for this service will have the desired naming with numbers removed.

If you have REST requests which have two numbers similarly you will need also another rule preceding the rule above and extracting prefix, infix and postfix parts of the URL and then constructing a new request name:

{
 "conditions": [
  {
   "attribute": "WEBREQUEST_URL_PATH",
   "comparisonInfo": {
    "caseSensitive": false,
    "comparison": "REGEX_MATCHES",
    "negate": false,
    "type": "STRING",
    "value": "\/\\d++\/[\/\\D-]*+\\d++",
    "values": null
   }
  },
  {
   "attribute": "SERVICE_TAG",
   "comparisonInfo": {
    "comparison": "TAG_KEY_EQUALS",
    "negate": false,
    "type": "TAG",
    "value": {
     "context": "CONTEXTLESS",
     "key": "REST Cleanup"
    },
    "values": null
   }
  }
 ],
 "enabled": true,
 "order": "REST 00",
 "managementZones": [],
 "metadata": {
  "clusterVersion": "1.220.96.20210701-171424",
  "configurationVersions": [
   0
  ]
 },
 "namingPattern": "{prefix}[ID]{infix}[ID]{postfix}",
 "placeholders": [
  {
   "aggregation": null,
   "attribute": "WEBREQUEST_URL_PATH",   
   "delimiterOrRegex": "^(.*?/)\\d+",
   "endDelimiter": null,
   "kind": "REGEX_EXTRACTION",
   "name": "prefix",
   "normalization": "ORIGINAL",
   "requestAttribute": null,
   "source": null,
   "useFromChildCalls": false
  },
  {
    "aggregation": null,
    "attribute": "WEBREQUEST_URL_PATH",   
    "delimiterOrRegex": "\/\\d++(\/[\/\\D-]*+)\\d++",
    "endDelimiter": null,
    "kind": "REGEX_EXTRACTION",
    "name": "infix",
    "normalization": "ORIGINAL",
    "requestAttribute": null,
    "source": null,
    "useFromChildCalls": false
   },
   {
   "aggregation": null,
   "attribute": "WEBREQUEST_URL_PATH",
   "delimiterOrRegex": "\/\\d++(\/[^\/]*+)$",
   "endDelimiter": null,
   "kind": "REGEX_EXTRACTION",
   "name": "postfix",
   "normalization": "ORIGINAL",
   "requestAttribute": null,
   "source": null,
   "useFromChildCalls": false
  }
 ]
}

 
To make it more simple to deploy, you can use the attached monaco project which makes those rules easily deployable.

[Malaik]

Thanks so much @Julius_Loman 

Question:

{prefix}, {infix}, and {postfix} should be replaced by the values from the table or we can declare them as a variables somewhere?

Have a good day.

[Julius_Loman]

@Malaik the placeholders {prefix}, {infix}, and {postfix} are extracted from the URL with regular expressions. See the placeholders section of the rule.

[Malaik]

Thanks @Julius_Loman right, my question was gone too quickly.

Have a good day.

[AurelienGravier]

Thank you for sharing this, @Julius_Loman .

It's an almost constant need for all build projects.

It's really unfortunate that the overall management of placeholders and request naming rules is still not available at the interface level (your article dates back to 2021!). It would be so much better for the client adoption by non-technical people.

Thx.

[MostafaHussein]

Great Tip!