Open dbwiddis opened 1 year ago
I am not sure how helpful of advice this will be, but I wanted to mention for whoever tackles this that it may be worthwhile to look at some of the principal resolution that is happening in the Identity project. Reading this description, it is somewhat similar in that you are treating the plugin name like an alias for the equivalent extension. You should be able treat it as two principals for the same subject in the case where there is only the extension running but not the plugin.
Looks like we can accomplish this by implementing the replacedRoutes()
extension point:
So we should revise rest handler registration to have the full path(s) generated on the SDK side.
Ignore me @dbwiddis is way faster than I am :)
For seamless migration for plugins RestHandler
[1] interface supports replaced paths to help deprecate old APIs and migrate to new API Paths.
Why would one want to run a plugin and an extension side-by-side on the same REST path?
One possible way to solve this is that all extensions have a configurable REST prefix and by default always register routes behind _extensions/prefix
by default. Thus I could install an extension with a default _extensions/ad
or _plugins/ad
by supplying a --prefix
parameter at installation time.
Why would one want to run a plugin and an extension side-by-side on the same REST path?
They wouldn't. A single REST path goes to exactly one handler.
They might want to run them side by side during transition to evaluate them, but in that case they would use different rest paths.
One possible way to solve this is that all extensions have a configurable REST prefix and by default always register routes behind
_extensions/prefix
by default.
That is how it is currently implemented.
There are three scenarios:
This last part (the sub bullet under 3) is the only real change, in order to provide backwards compatibility with scripts / dashboards / etc. that use the old route, similarly to how we have replaced routes going to the same handler as the old one; both work.
Is your feature request related to a problem?
Users migrating from a plugin to an extension should ideally not have to change anything.
Currently plugin rest paths include hardcoded names such as
_plugins/_anomaly_detection/foo
.Extension rest paths include the ability to specify the unique ID (e.g.,
ad
) and change the prefix, so the same request would be_extensions/_ad/foo
.If users want to run both the plugin and extension side by side, this does not conflict. However in a migration context, we want the ability for
plugin
to redirect toextension
.What solution would you like?
During Extension initialization, Extensions register their paths with the RestController. This logic should be updated:
uniqueId
matches a list of known plugin namesuniqueId
matches a known plugin name:_extension
path, make an attempt to register the_plugin
path. If this results in an exception (already registered by the plugin) then catch and log the exception.This will allow the following configurations:
What alternatives have you considered?
Do you have any additional context?