Improve API consistency

[disposedtrolley]

Hello again!

This PR improves some of the resource APIs to be more aligned with REST best practices. It:

• adds response envelopes for several endpoints which had top-level JSON arrays
• ⚠️ Breaking change: changes responses containing a 1 in the body to return a 204 No Content status with an empty body instead
• ⚠️ Breaking change: renames the PUT /api/tag endpoint to /api/tags
• updates the Postman collection

I've also generated a new bundle for the frontend since some of the API changes required changes to the associated JS files.

[deanishe]

Hi @disposedtrolley, thanks for the PR.

Looks good. Could you rebase on master/fix the conflicts?

[disposedtrolley]

@deanishe all fixed up now!

[fmartingr]

Hello from the present @disposedtrolley, thanks for your contribution! How do you feel on continuing working on this? Don't worry if you wont, I can follow up on this issue myself!
But please, if you do rebase this with the latest master, can you avoid committing any style changes not relevant to the PR itself? It will be of great help (and it will likely avoid having to rebase again if we change any of those files). Thanks again!

[disposedtrolley]

Hey @fmartingr, happy 2022!

I'm a little worried about introducing breaking changes to the API actually; I felt this was appropriate in 2019, but I'm sure the community and ecosystem has grown much since then, and I want to make sure we keep any downstream consumers happy.

What do you think?

[fmartingr]

It makes sense.

But sooner or later we may need to version the API, with a proper session persistence via JWT, unifying endpoints with the extension and so on. When I reach that point I will make sure to influence myself with your submission :)

[disposedtrolley]

@fmartingr I've fixed the merge conflicts by re-doing my changes from scratch. I've also dropped the commit that was formatting errors from panics into a nice response body. I'd like to remove the body entirely at some point as I don't think we should be exposing internal error messages to consumers.

Let me know what you think!

[fmartingr]

Hey @disposedtrolley, good work! I'm going to mark this change for 1.6.0 for now. After that I need to start creating task for a proper v1 API, but there are a lot of things to do before that.

I don't think we should be exposing internal error messages to consumers.

You're totally right. (Relates to #236)

[fmartingr]

Hey @disposedtrolley, if you can fix those conflicts we can move forward with this to test it before the next release :)