Dedicated dashboard & saved object APIs

[matschaffer]

Describe the feature:

Add dedicated kibana server routes for at least:

• dashboards
• data views

(could be split out into separate issues, but keeping together for now)

Describe a specific use case for the feature:

There are lots of folks around automating kibana configuration. @wandergeek among them (internal user).

Today it looks like the only API we have for this is https://github.com/elastic/kibana/blob/main/src/plugins/saved_objects_management/server/routes/find.ts#L28

The API is "experimental" but probably sees use since it's the only option (aside from direct ES index manipulation) available for automating kibana configuration.

Rel: #90429 - touches on the need for moving away from a single API, but is mainly focused on considering the current api "beta"

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[mattkime]

We have a data views api, a minor update on the index patterns api. Docs will be merged shortly but are currently here - #123111

We should get the specifics of what you need for a find endpoint.

[pgayvallet]

@matschaffer could you elaborate a bit on the exact need, and on why using the _find http API directly exposed from core would be a problem for it?

Btw, the route you linked is an 'internal' route for the SO management plugin. Core's find route is exposed via /api/saved_objects/_find.

kibana/src/core/server/saved_objects/routes/find.ts

Lines 27 to 30 in dfea0fe

	router.get(
	{
	path: '/_find',
	validate: {

Also, note that we all agree that in the long term, having per SO type endpoints is the way to go (#72028), but we're not here yet

[matschaffer]

ah, thanks!

So long as there's a stable public API I think @wandergeek 's needs should be served.

I guess one small worry about a generic saved_object/_find is what happens when names change. For example today I think it's still finding type=index-patterns. Presumably this will be type=data-views, when we make that change we'll probably break backward compatibility with anyone using the API to synchronize index patterns.

In a worst-case scenario we could end up wiping out all the IaC-managed index patterns (now data views) by receiving an empty set from a type=index-patterns query.

The existence of a dedicated api might help us remember to have some form of backward compat (at least a helpful error message) when changing names of things.

[mattkime]

@matschaffer

Agreed - that said, we plan on living with type=index-patterns as long as possible. Migrations can be a source of problems and IMO should be avoided whenever possible.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[rudolf]

Removing the core label as just like app services introduced a dedicated API for data views, there's nothing holding the presentation team back from introducing a dedicated dashboard API. For the reasons outlined in this issue and #72028 the core team would highly recommend that the presentation team creates a dedicated dashboard HTTP API

[ThomThomson]

While this is something that's important, and we will most likely get to it in the future, this is not part of our current roadmap, and will not be added to it in the next few minors. Because of this, I will move this issue into our icebox. We can always reopen if our priorities change.