This way, or the possibility is to go the other way around, and fix the old route so
it can work without the "useless" parameters (but also with them).
I'm just not sure why this variant, can you state it in the commit message?

Side note: what #1352 shows us is that people care and will care more about
the API quality. And it seems that we should really pay attention to consistency,
and/or start documenting even the API.

This way, or the possibility is to go the other way around, and fix the old route so
it can work without the "useless" parameters (but also with them).
I'm just not sure why this variant, can you state it in the commit message?

Actually, I think I did this. By "I am not changing the original route
on frontend to avoid breaking a backward compatibility, but rather
adding a new simple route." I didn't mean copy-pasting the whole
route/view function (argh, I always mistake them because Flask uses a
different teminology then some other web frameworks). By adding a new
"route" I meant simply adding a new @apiv3_ns.route decorator for
the existing function ... so it can be accessed via URL with or
without the "useless" parameters.

I updated the commit message so hopefully it is not that confusing anymore.

Side note: what #1352 shows us is that people care and will care more about
the API quality. And it seems that we should really pay attention to consistency,
and/or start documenting even the API.

I totally agree, we should investigate how to document our API
properly.

I meant that there's an option to make this work:

1) /api_3/build-chroot/1341930/fedora-rawhide-x86_64

... as well as compat variant:

 2) /api_3/build-chroot/1341930/fedora-rawhide-x86_64?build_id=1341930&chrootname=fedora-rawhide-x86_64

I have no problem with the variant you prefer:

3) /api_3/build-chroot?build_id=1341930&chrootname=fedora-rawhide-x86_64

But I'm not sure whether we shouldn't make 1) work as well.

Ah, I see, thank you for the explanation.

But I'm not sure whether we shouldn't make 1) work as well.

IMHO no, for other GET routes, we use just 3), e.g.

endpoint = "/project"
params = {
"ownername": ownername,
"projectname": projectname,
}

---

endpoint = "/project/list"
params = {
"ownername": ownername,
}

---

endpoint = "/project/search"
params = {
"query": query,
}

---

endpoint = "/project-chroot"
params = {
"ownername": ownername,
"projectname": projectname,
"chrootname": chrootname,
}

---

endpoint = "/project-chroot/build-config"
params = {
"ownername": ownername,
"projectname": projectname,
"chrootname": chrootname,
}

---

endpoint = "/build/list"
params = {
"ownername": ownername,
"projectname": projectname,
"packagename": packagename,
"status": status,
}

and the 1) format is not supported. There is a couple of exceptions though, regarding getting a single build:

endpoint = "/build/{0}".format(build_id)
endpoint = "/build/source-chroot/{0}".format(build_id)
endpoint = "/build/source-build-config/{0}".format(build_id)

If we wanted to unify all of that, my preference would be to migrate
everything to 3) instead of 1) because it is IMHO superior. It is a
bit longer, yes, but it allows to pass arguments in a random order as
well as passing optional arguments in the same way as the required
ones, which is really cool in routes like /build/list, see above.

If we wanted to unify all routes and support both 1) and 3) format for
all of them, I wouldn't be against, but it needs to be done in a
separate PR and I would stick with exclusively using 3) in python-copr client.

What do you think?

Agreed.

+1

Commit 5bfd679 fixes this pull-request