Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] There should be a way to enumerate all routes of OpenSearch #3349

Open
peternied opened this issue May 17, 2022 · 1 comment
Open
Labels
distributed framework enhancement Enhancement or improvement to existing feature or request

Comments

@peternied
Copy link
Member

peternied commented May 17, 2022

Is your feature request related to a problem? Please describe.
As a plugin developer, we've added several APIs and missed supporting our legacy or new route scheme, seeing the routes would give us a way to confirm we've done the right thing.

Additionally as an operator of an OpenSearch cluster it is useful to see the available APIs when I am forgetful or if I want to understand the surface area of the service.

Describe the solution you'd like
Similar to the /_cat/ call there would be a way to inventory all the supported routes of OpenSearch including the installed plugins.

%  curl https://localhost:9200/_cat/routes
|\---/|
| o_o |
 \_^_/
/_cat/allocation [GET]
/_cat/routes [GET]
...
/_plugins/_alerting/monitor/{monitor_id} [GET, POST, PUT, DELETE]
/_plugins/_alerting/monitors/_search [GET, POST]
/_plugins/_alerting/stats [GET]
/_plugins/_alerting/stats/{metric} [GET]

Describe alternatives you've considered
While these registered routes could be displayed output to the log, that doesn't seem as useful for a more adhoc check, but that would be useful for system administrators if they want to make sure they know the capabilities of the cluster.

Additional context

@peternied peternied added enhancement Enhancement or improvement to existing feature or request untriaged labels May 17, 2022
@dblock
Copy link
Member

dblock commented May 18, 2022

The RESTful API should be generated from spec (#3090), making this easy. The service would just return the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
distributed framework enhancement Enhancement or improvement to existing feature or request
Projects
None yet
Development

No branches or pull requests

4 participants