+1 for this, as it would liberate us in many cases from webserver timeout constraint, also output could be streamed directly to file = easy reports for download generation.

It would be ok for me although I don't need it therefore has no priority for me. I do not really see which problem it solves. If it is about constructing URL's why not something for the UI? There are even tools for this but they mainly require REST like APIs. Also I would prefer if this would not automatically use super user permission.

If this is added to core, I think it should be added to climulti:request (or alternatively, climulti should use this instead of climulti:request). As far as I can tell, climulti:request also calls the API (though maybe not as superuser).

Maybe we could do it simple for MVP (eg. without autocompletion), as a quick "shortcut" that would re-use climulti:request command.

I still don't get what the actual problem is that will be solved here.

Why a core:api command? There are currently dozens of APIs and it can be complicated to build a correct URL and input this in the console.

Why does one has to input this in the console when requesting an API etc?

For example to store the API results in a file, or to get a static image and store it as image file, or to call "invalidate archived reports" API without browser timing issues, and maybe other use cases?

call "invalidate archived reports" API without browser timing issues

sounds like a problem :) Maybe a separate command for this would be better? Otherwise the issue sounds to me like "I have an idea" let's find the problem :) Eg wget can be used to save API output etc. but if people actually have a need to do this often then this command seems to solve it.