-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[new-platform] Differentiate between Public and Internal APIs #40623
Comments
Pinging @elastic/kibana-platform |
Also, there is a request to distinguish API URLs from other resources. It can be covered by this proposal as well. @elastic/kibana-security what does system api that you heavily use stand for? |
We use this to differentiate between requests that were initiated by the end user versus requests that are initiated by the system. When it's an "end user initiated request" we want to extend the user's session to prevent them from being logged out for being idle. Where-as when it's a "system initiated request", most commonly background requests which don't signal true end-user activity like polling for new reporting jobs, we don't extend the user's session. |
I see, that is a different use case. Could we leverage route tags for this? |
It's possible, but it'd potentially require use to duplicate routes for us to do this entirely properly. For Reporting, we used to use the same routes for polling in the background as we did in the foreground for listing reporting jobs. It looks like there have been some recent changes so all of these requests have that system-api header even though they technically shouldn't. |
Yeah, using tags to cover "system api" requests use case can be cumbersome and may not solve the problem completely anyway: there will definitely be client side abstractions at some point that will be hitting one route or another under the hood and apps/plugins may use these abstractions (e.g. But yeah, it's a completely different topic and seems to be outside of |
related #21424 |
closed in favour of #21424 |
APIs registered by plugins could benefit from having an explicit difference between public and internal APIs.
Additionally, these two types of APIs could have different URL prefixes. For example:
pluginA
:/api/pluginA/myRoute
pluginA
:/internal/pluginA/myRoute
Benefits:
Related to #12464
The text was updated successfully, but these errors were encountered: