Kibana low and high level language clients

[alexfrancoeur]

As we continue to add more stable API's, such as our saved object management, space management and up and coming services focused on alert generation, it would be great to add standardized client libraries for these REST API's.

This would consist of a low level API (like elasticsearch-py) and a high level language client that uses the low level one (like elasticsearch-dsl), using Elasticsearch/Python as an example language client.

[karmi]

We have talked about this topic among the clients as well, and we're all for it.

Note that the first step here is to come up with a format for the API specification. For the Elasticsearch APIs, we have a custom format, which the generators for existing language clients consume. But I think we're open to discuss a different format, eg. OpenAPI/Swagger, if it makes more sense for this particular use case.

/cc @elastic/es-clients

[philkra]

@alexfrancoeur , I'm happy to start a discussion on this subject.

/cc @epixa

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[joshdover]

This has come up a few times (#21424, #44620) and there seems to be a lot of interest around OpenAPI.

While there's definitely nothing stopping someone from starting on this now, our intentions here have been to wait until we could build high-quality integrations between the API spec, generated documentation, runtime request validation, and actual use of the generated API clients within Kibana's frontend code.

The Platform team definitely has an interest in making this happen and is happy to provide guidance here, but until the New Platform migration is closer to complete, I'm not sure we'll be able to help with implementing support.

[pmuellr]

re: OpenAPI, see this existing usage in ESS: https://www.elastic.co/guide/en/cloud/current/ec-openapi-specification.html

It would be interesting to play with this existing spec we have to see how easy it is to create bindings for a couple of languages. We'd at least learn where the sharp edges are in the API design.

[rudolf]

Interesting, it would also be interesting to see how they generate the asciidocs published on our docs website.

[Mpdreamz]

Our wonderful docs team has tooling to generate API reference ascii docs from OpenAPI cc @debadair

(Some of our clients also have openapi generators ready to go :))

[pgayvallet]

FYI, I just created #82587 to discuss about the feasibility of automated OpenAPI spec generation.

[lukeelmers]

Related elastic/terraform-provider-elasticstack#100

[pgayvallet]

AFAIK, lot of more recent issues have been created along the years regarding that topic. I'll close in favor of, say, #180056