Hey Stefan,
Looks like you are well ahead in the game considering we don’t have any code yet. Buy yes, both are good ideas.
I think that 1 though will be slightly different, because going forwards I’ll be moving report generation to a background queue, meaning that it won’t be processed synchronously. So most likely you’ll get a Job UUID for your reporting request and then you can poll the server to check the job completion status. Once completed you’ll get a URL to download the report. Or something like that.
I’ve already added infrastructure to the repo to have versioned APIs which I think will be key to allow for a more organic growth of the interface (e.g. v1 ships with CRUD operations for basic classes, then in v2 we move on to CRUD for other classes, in v3 … etc. It’s just an example though).
Thanks for sharing these ideas.