mstoykov
commented
8 months ago Sorry for the slow reply :bow:.
I think we discussed this in private for the specific case of the web dashboard and decided that it is not a great idea to have both a controlling and not controlling API on the same port. Especially if people decide to export and share the web dashboard endpoint.
From my perspective that will be the case for more or less every other case as well. Another thing is that the major reason to export endpoint so far has been stuff such metric outputs, for example prometheus scraping. And those already have well known ports that they are expected on.
So from UX perspective it seems like most cases will just never want to add an endpoint under the k6 REST API.
I currently don't see a good case for this, so if we are not going to need it for the web dashboard I am for closing this.
Feature Description
Certain extensions (primarily output extensions) provide services available via the HTTP protocol (REST API, HTML pages, etc.). These extensions start their own HTTP server on different ports. It would be useful to provide a common HTTP server within the k6 process that can be used by extensions.
FYI @oleiade
Suggested Solution (optional)
At startup, k6 also starts an HTTP server (default port 6565) for REST API service. It seems logical to make this HTTP server available to extensions via an API. Using this API, extensions could register an HTTP handler for a given route.
Already existing or connected issues / PRs (optional)
No response