[FEATURE] Add OpenSearch Dashboards API specifications

[Swiddis]

Is your feature request related to a problem?

It looks like all of the endpoints added here thus far are for OpenSearch and not Dashboards, and I don't see any issues related to Dashboards plugins or core endpoints (though #236 is close). While not part of the core OpenSearch cluster environment, there is nonetheless demand for formalization of (some) OpenSearch Dashboards endpoints.

Taking the saved object API as the example I've worked with most: there's an open stabilization issue https://github.com/opensearch-project/OpenSearch-Dashboards/issues/6310. While the saved objects endpoints aren't part of base OpenSearch, they're nonetheless widely used by multiple plugins (and there have been bugs by failing to replicate its features). Later when implementing an object upload flyout I found I had to do a lot of digging through the OSD source code to reverse-engineer how the _import API is meant to be used.

What solution would you like?

I'm not sure how in-scope it is to try and document the entire OSD API tree like what's being worked on for OS here: the use case for directly calling these endpoints is probably less prevalent than direct OS queries. But having access to good documentation for these endpoints would help both OSD plugin authors and users attempting to invoke OSD functions directly.

A simple way to get started is to add a section for adding these APIs and let it live alongside the OS specifications, without necessarily pursuing every plugin like what we did for the OS plugins, and calling on plugin authors to add major endpoints.

What alternatives have you considered?

We could just bundle these APIs with the existing OS endpoints since there's strictly not an "opensearch" namespace used here. It feels messy, but is probably more straightforward.

Do you have any additional context?

N/A

[dblock]

I think we should welcome the OpenSearch Dashboards API spec in this repo. There are a few challenges on just adding them to the existing spec, so I feel like a separate folder structure for OpenSearch and OpenSearch Dashboards is a better idea.

1. The API test coverage will need to be extended. Currently we use https://github.com/dblock/opensearch-api, a plugin that generates at runtime a list of OpenSearch APIs, something similar will need to be developed for OpenSearch Dashboards.
2. The tests boot an instance of OpenSearch in Docker. There's no need to tie these two together.

What to give something basic a try @Swiddis?

[Swiddis]

I'm happy to contribute to some of it, but I may not have bandwidth to do a full implementation for a while. It may be worthwhile to try and split it into smaller tasks, and I can take some subset of them. Based on what you've written I'm assuming a list might include:

• [ ] Write a tool to scrape all endpoints from OSD (possibly a plugin?) and export it to be recycled for API coverage
  • I'm hesitant to say "let's put all the APIs on the roster" because I think many frontend APIs are more volatile than back-end counterparts. Should there be some sort of opt-in system?
• [ ] Write a workflow to do API tests through OSD, or steal an existing one (functional test repo?)
• [ ] Actually do the directory creation and integrate with the previous steps
• [ ] Document/test some endpoints as a proof of concept

[dblock]

Write a tool to scrape all endpoints from OSD (possibly a plugin?) and export it to be recycled for API coverage

I would do this last.

Write a workflow to do API tests through OSD, or steal an existing one (functional test repo?)

I would use what we have in this repo "as is", just boot an instance of OpenSearch Dashboards instead of OpenSearch for testing.