When looking at https://github.com/elastic/kibana/issues/182594, I checked the alerting APIs to see if we'd have any "overlapping" URLs, if we relaxed the requirement that rule id's have to be UUIDs.
There are at least two that would overlap:
GET /internal/alerting/rule/{id}
GET /internal/alerting/rules/_find
Today, they can't overlap, because you can provide an arbitrary id when creating rules, but it must be a valid UUID. Once that's relaxed, someone could create a rule with an id of _find, and then the first URL will never be routed for that id.
It would be nice to have some build-time support for this, perhaps as a jest integration test making use of router.getRoute() to get the routes and "check them". It will need information on how varied the values can be. For instance, today we'd want to indicate the rule id has to be a UUID.
Seems a bit messy, guessing we would need to add some meta data to the routes to help out with this. But would be very useful I think.
When looking at https://github.com/elastic/kibana/issues/182594, I checked the alerting APIs to see if we'd have any "overlapping" URLs, if we relaxed the requirement that rule id's have to be UUIDs.
There are at least two that would overlap:
GET /internal/alerting/rule/{id}
GET /internal/alerting/rules/_find
Today, they can't overlap, because you can provide an arbitrary id when creating rules, but it must be a valid UUID. Once that's relaxed, someone could create a rule with an id of
_find
, and then the first URL will never be routed for that id.It would be nice to have some build-time support for this, perhaps as a jest integration test making use of
router.getRoute()
to get the routes and "check them". It will need information on how varied the values can be. For instance, today we'd want to indicate the rule id has to be a UUID.Seems a bit messy, guessing we would need to add some meta data to the routes to help out with this. But would be very useful I think.