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

Versioned API Router #149286

Closed
exalate-issue-sync bot opened this issue Jan 20, 2023 · 5 comments · Fixed by #153543
Closed

Versioned API Router #149286

exalate-issue-sync bot opened this issue Jan 20, 2023 · 5 comments · Fixed by #153543
Assignees
Labels
Epic:VersionedAPIs Kibana Versioned APIs Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@exalate-issue-sync
Copy link

exalate-issue-sync bot commented Jan 20, 2023

All plugins need to implement a versioned API layer. But we don't want each plugin to have to implement basic functionality like versioning. How can we enable teams to have their APIs conform to the Elastic versioning strategy (#149285) without having to implement it from the ground up every time?

@botelastic botelastic bot added the needs-team Issues missing a team label label Jan 20, 2023
@jloleysens jloleysens added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Epic:VersionedAPIs Kibana Versioned APIs and removed needs-team Issues missing a team label labels Jan 20, 2023
@jloleysens jloleysens self-assigned this Jan 20, 2023
@lukeelmers
Copy link
Member

When exploring our design options here, we should consider whether this would also be a good opportunity to introduce a mechanism for more formally labeling routes as "internal": #151940

@jloleysens
Copy link
Contributor

Initial design PR #151596

@TinaHeiligers
Copy link
Contributor

@jloleysens when do we plan on tackling the implementations (server & client-side)?

@TinaHeiligers
Copy link
Contributor

TinaHeiligers commented Feb 26, 2023

introduce a mechanism for more formally labeling routes as "internal"

I've started looking into this.

@rudolf rudolf reopened this Mar 7, 2023
@rudolf
Copy link
Contributor

rudolf commented Mar 9, 2023

We don't have 100% confidence in the exact version negotiation mechanism, but we believe it should be a low amount of effort to make adjustments to the negotiation mechanism later if necessary so we'll start on this already.

jloleysens added a commit that referenced this issue Mar 28, 2023
## Summary

Implements the designs from
#151596

* Move `packages/versioning/*` into `packages/core/http` to follow
existing structure more closely
* Implements the first iteration of the versioned router as a
wrapper/layer around the existing router
* Adds some integration tests
* Future work needed! Once we have a the versioned spec we should
implement it in this wrapper layer
* Validation is a little bit tricky because of when the
`CoreKibanaResponse` object is instantiated, the approach taken here is
to replace body, params, query on the route-level's request object

Closes #149286

---------

Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic:VersionedAPIs Kibana Versioned APIs Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants