[Alerting] url collision between pre-registered actions and existing GET urls

[pmuellr]

With the new support for pre-registered actions added in PR #62382, there is now a potential for URL collision with GET requests.

Here's a table of all the current endpoints supported by actions: (the base uri is /api/action)

method	uri	description
POST	/	create
DELETE	/{id}	delete
POST	/{id}/_execute	execute
GET	/{id}	get
GET	/_getAll	get_all
GET	/types	list_action_types
PUT	/{id}	update

So the problem is with the GET requests. A pre-registered id of _getAll or types could end up matching the get_all or list_action_types endpoints, OR trying to do a GET on a pre-registered action with that id would return the existing function. Not clear which would win, but they are both wrong.

Black-listing pre-registered ids is possible, but problematic, as we'd have to keep the black-listed id's up-to-date with our endpoints, and if we forgot when we added a new GET endpoint ... we'd have a problem. I'm sure we'd forget :-)

One way to fix this would be to require a new prefix on the get function, changing the uri from /{id} to /object/{id} instead (probably not object, but a fixed prefix of some kind).

As a side note, the _getAll uri looks a little out-of-place - should it be getAll or get_all? The /types uri is also implemented (equivalently) in alerts, so any changes to should probably be reflected there. We don't currently have thoughts on creating pre-registered alerts soon, but perhaps we should look at that URI structure as well. I wonder if we should have the "get_all" functionality implemented as GET /?

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

Should be done at the same time / person as #59799.