### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 6, 2021, 2:05pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/1 "2021-05-06T14:05:11Z")
While we are upgrading all the ODFE plugins to work with OpenSearch, we realized all the APIs, settings, indices etc had a prefix of `opendistro`.
How would you like to see all things plugins in `opensearch-project` ? Would you like to have `opensearch` prefixed for every API, settings, indices etc? Or the other way round?
Example:
```auto
POST _opendistro/_anomaly_detection/detectors to POST _opensearch/_anomaly_detection/detectors or POST _anomaly_detection/detectors
```
Here is the github issue if you’d like to chime in there.
>
>
> Currently, all plugins have followed the same convention of prefixing all APIs w…ith \`\_opendistro/\*\` to represent that they were APIs supported by the Open Distro for Elasticsearch project. Now, these plugins are more closely associated with the core \`OpenSearch/OpenSearch Dashboards\` source code itself.
>
> One option is removing the \`\_opendistro\` prefix entirely, and allowing the OpenSearch plugins to shorten and simplify their paths. Example: \`\_opendistro/\_anomaly\_detection/\*\` -\> \` \_anomaly\_detection/\*\`.
>
> Another option is to replace \`\_opendistro\` with \`\_opensearch\`, but I feel this may be a bit unnecessary and repetitive in this case.
>
> If something like the first option is decided upon, we may apply similar strategies for other areas that need migration from \`opendistro\`, including system indices, cluster settings, etc. as mentioned in #12
>
> Creating this issue as a point of discussion on possible solutions to migrate the current plugin REST APIs.
---
### Author:  [@hagayg](https://forum.opensearch.org/u/hagayg)
#### Post date: [May 6, 2021, 2:22pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/2 "2021-05-06T14:22:39Z")
Maybe start with a deprecation warning while supporting both endpoints at first and change it a few versions in? The concern is obviously backwards compatibility
---
### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 6, 2021, 2:37pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/3 "2021-05-06T14:37:21Z")
Thats a great point. Definitely. We will always be backwards compatible, support the old API for a while and if needed could be deprecated in later versions.
Mostly the question is about what should be the new/existing APIs/indices etc be named to?
---
### Author:  [@hagayg](https://forum.opensearch.org/u/hagayg)
#### Post date: [May 6, 2021, 3:16pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/4 "2021-05-06T15:16:22Z")
I am guessing the simplest solution would be a general redirect of [cluster]/\_opendistro/\* to [cluster] /\_opensearch/\*, and that should probably take care of that as well
---
### Author:  [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)
#### Post date: [May 6, 2021, 4:48pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/5 "2021-05-06T16:48:25Z")
Also - any changes to this would be post 1.0 GA, right?
---
### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 6, 2021, 4:56pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/6 "2021-05-06T16:56:37Z")
Since we have decided ODFE is end of life. I believe these changes should be part of 1.0 GA, i.e get rid of `opendistro` everywhere. Do you have other suggestions/thoughts?
---
### Author:  [@searchymcsearchface](https://forum.opensearch.org/u/searchymcsearchface)
#### Post date: [May 6, 2021, 4:59pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/7 "2021-05-06T16:59:59Z")
That would make a breaking change - I’m pretty sure the project is committed to no breaking changes in 1.0.
---
### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 6, 2021, 5:07pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/8 "2021-05-06T17:07:22Z")
Yeah definitely. We will not make breaking changes. All changes we make will be backwards compatible and we are putting our thoughts into it.
Here are the items which are named `opendistro` today: [Support rolling upgrades for OpenSearch plugins, and restart upgrades for OpenSearch Dashboards Plugins 1.0 · Issue #12 · opensearch-project/opensearch-plugins · GitHub](https://github.com/opensearch-project/opensearch-plugins/issues/12)
---
### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 7, 2021, 4:54pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/10 "2021-05-07T16:54:42Z")
Re-posting the comment from github issue, just another thought.
We could meet somewhere in between which works for everybody.
What do you guys think of something like `_opendistro/_anomaly_detection/*` → `_plugins/_anomaly_detection/*` .
No more having OpenSearch in it, also we can clearly distinguish that these paths are from plugins.
Same with indices, settings, permissions etc. Please vote/voice your opinions.
---
### Author:  [@ohltyler](https://forum.opensearch.org/u/ohltyler)
#### Post date: [May 7, 2021, 5:00pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/11 "2021-05-07T17:00:11Z")
+1, I like the idea of `_plugins`.
---
### Author:  [@wnbts](https://forum.opensearch.org/u/wnbts)
#### Post date: [May 7, 2021, 9:31pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/12 "2021-05-07T21:31:16Z")
+1 \_plugins . project/product name doesn’t seem necessary in api.
---
### Author:  [@amitai](https://forum.opensearch.org/u/amitai)
#### Post date: [May 9, 2021, 1:50pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/13 "2021-05-09T13:50:01Z")
+1 \_plugins 🙂
This fits what I would normally expect an API to look like.
---
### Author:  [@ralph](https://forum.opensearch.org/u/ralph)
#### Post date: [May 10, 2021, 6:23am UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/14 "2021-05-10T06:23:57Z")
how do you ensure that two plugins from different “vendors” (i’m using this as a generic term here, they don’t have to be companies, can also be a random person on github) don’t use the same name? you probably don’t have a copyright/trademark e.g. on `_anomaly_detection` (and even if you do, others might not have one on their plugin name). using a vendor prefix usually alleviates these issues.
it’s the same with java: you also don’t name your package `foo`, you name it `org.opensearch.foo` because `foo` isn’t unique.
using `_plugins` as another prefix in front of that in turn helps prevent that any vendor (or, if you leave that out, plugin) name collides with any future plans for new endpoints in the core product. otherwise you’d either need a complete list of all plugins which exist (which you can’t have since some will probably never be published) or accept potentially breaking a plugin (making _any_ new API endpoint automatically a new major release according to semver).
=\> i’d go for `/_plugins/somevendor/someplugin`. so in your example `/_plugins/opensearch/_anomaly_detection`.
which brings me to the next question: why the `_` prefix for the plugin name? if it’s prefixed with `/_plugins` you don’t need it in the plugin name again. and also for `/_plugins` i’m not sure whether you need the `_` prefix (though that might be an elasticsearch/opensearch convention? there are a bunch of APIs with this prefix)
you _could_ treat opensearch core plugins in a special way and e.g. say that instead of writing `opensearch` as the vendor you can shorten it to just `_` =\> `/_plugins/_/anomaly_detection`
lastly: why the snake\_case in the plugin name in the URL? most REST API guidelines (see e.g. [Zalando RESTful API and Event Guidelines](https://opensource.zalando.com/restful-api-guidelines/#129)) mandate hyphenated words in the path segments.
---
### Author:  [@amitai](https://forum.opensearch.org/u/amitai)
#### Post date: [May 10, 2021, 8:29am UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/15 "2021-05-10T08:29:43Z")
> [@ralph](#):
>
> most REST API guidelines (see e.g. [Zalando RESTful API and Event Guidelines](https://opensource.zalando.com/restful-api-guidelines/#129)) mandate hyphenated words in the path segments
+1 for this.
@ralph - Isn’t this API only relevant to the OpenSearch project’s plugins? Otherwise, yes you are correct that a “vendor” may be required in the path.
---
### Author:  [@ralph](https://forum.opensearch.org/u/ralph)
#### Post date: [May 10, 2021, 8:36am UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/16 "2021-05-10T08:36:34Z")
> [@amitai](#):
>
> @ralph - Isn’t this API only relevant to the OpenSearch project’s plugins? Otherwise, yes you are correct that a “vendor” may be required in the path.
the discussion was so far focusing on renaming opendistro plugins to opensearch plugins, that’s true. i took it and kind-of spun it out a bit to a wider discussion. i have a tendency to do that, sorry about that 😃
---
### Author:  [@vemsarat](https://forum.opensearch.org/u/vemsarat)
#### Post date: [May 11, 2021, 6:10pm UTC](https://forum.opensearch.org/t/thoughts-on-having-opensearch-identifier-in-all-things-plugins/5855/17 "2021-05-11T18:10:47Z")
🙂 Thanks @ralph for putting in thoughts beyond opendistro plugins. I intended to cover all the plugins in the community, and taking opendistro as an example to start with.
I did go through the Rest API guidelines, but OpenSearch pretty much follows that convention of using `_` instead of `-`. So it makes sense for the plugins to continue to do that until OpenSearch changes its convention. We could open up an issue on the OpenSearch repo to discuss and vote on it.
Looks like everybody likes for `_plugins/_anomaly_detection`, and it’s sold.
I’ll update the github issue.
Anybody if they have strong opinions against this, please voice out.