QA » openQA Project

I'd rather make it a warning or at least allow forcing the API-base via an environment variable.

mkittler wrote:

I'd rather make it a warning or at least allow forcing the API-base via an environment variable.

Warning against what?

I was asking this in the original ticket: Can't we require that whatever the path is actually is openQA API? Regardless if it's / or v15 or whatever

@okurz @mkittler @cdywan

As a user, I hope some soft handling way can be used, rather than direct error and stops further handling.

Please let me share my personal opinion, but due to limited understanding of openqa, I can be wrong at some points, please correct me.

In the original ticket https://progress.opensuse.org/issues/90818#note-14, I asked "What is the intended web api(restapi) that client script supports to get group overview json format output?" and oliver replied "There is none.".
My understanding of restapi is that a web application that follows restapi conventions well should provide restful api for any route, so for openqa, eg group_overview, it should also provide a restful api for it, rather than what currently it is in https://openqa.nue.suse.com/what_are_supported_api_routes that only those under /api/v1 is the restful api while /group_overview/groupid:num is not(but it is supported route also). However, the command line tool of openqa, openqa-client(and the new openqa-cli) which is designed to use restful apis to perform web similar operations, has no way to query group_overview json output. That means the command line tool is even more limited than web, but IMHO command line tool should be more powerful.

So as a user, I would suggest that the command line tool openqa-client(and the new openqa-cli) can be made capable to perform all supported routes in https://openqa.nue.suse.com/what_are_supported_api_routes, no matter it is restful or not, rather than report errors to stop further actions.

Warning against what?

Obviously that one would get a warning when accessing a non-API route instead of just completely preventing it.

@xlai In openQA we differentiate between routes providing the web GUI and routes of the REST-API. The web GUI's routes return HTML content, CSS, SVG, JavaScript and various other formats. They return what's necessary to provide the GUI. The REST-API routes on the other hand return only JSON documents and only routes under /api belong to the REST-API. Note that the .json versions which are provided by some of the web GUI routes should not be considered a stable API. You can use them but you'll have to expect that their structure might change at any time.

If some required information is only exposed through the web GUI and not the REST-API we might want to extend the REST-API.

mkittler wrote:

If some required information is only exposed through the web GUI and not the REST-API we might want to extend the REST-API.

Yeah, that's what I'm also thinking now. The REST API should support all of the use cases. If it doesn't support a case I'd consider that internal/legacy.

In the sense that openqa-client should support this use case I agree with @xlai although I think it means we need to add a new route.