Project

General

Profile

Actions

action #91004

open

Treat '--apibase /' argument for openqa-client as error

Added by okurz almost 3 years ago. Updated almost 3 years ago.

Status:
Workable
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2021-04-12
Due date:
% Done:

0%

Estimated time:

Description

Motivation

See #90818#note-12

Acceptance criteria

  • AC1: An invocation of `openqa-client --apibase /' is treated as error with helpful error message

Related issues 1 (0 open1 closed)

Related to openQA Project - action #90818: [openqa][tool] Not able to get group_overview json output.Resolvedokurz2021-04-082021-04-22

Actions
Actions #1

Updated by okurz almost 3 years ago

  • Related to action #90818: [openqa][tool] Not able to get group_overview json output. added
Actions #2

Updated by mkittler almost 3 years ago

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

Actions #3

Updated by livdywan almost 3 years ago

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

Actions #4

Updated by xlai almost 3 years ago

@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.

Actions #5

Updated by mkittler almost 3 years ago

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.

Actions #6

Updated by livdywan almost 3 years ago

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.

Actions #7

Updated by okurz almost 3 years ago

  • Priority changed from Normal to Low
  • Target version changed from Ready to future

Well, I guess after all this isn't that clear and maybe also not that important.

Actions

Also available in: Atom PDF