fix: Move all parameters from query to JSON body

[provokateurin]

Closes #88

This fixes a lot of cases where the query parameters was just typed as string because it was not possible to correctly set the type.

[come-nc]

Tested on security_guard and looks promising.

[nickvergessen]

Needs at least more documentation

[provokateurin]

I will still have to do some testing to ensure the updated specs are correct.

[provokateurin]

My API unit test suite from https://github.com/nextcloud/neon/tree/main/packages/nextcloud/test confirms that these specs work exactly as intended. From my side this is ready to be merged.

[come-nc]

Does this work fine with ocs_api_viewer app?

[provokateurin]

It should, but let me give it a try

[provokateurin]

Oof, it seems like ocs_api_viewer is broken in that regard because it doesn't send the body at all. This has to be a bug in the library as the body is also not added to the code examples, but I couldn't find an issue about it 🤔

[provokateurin]

After another quick check it makes somewhat sense: GET requests are "not allowed" to have request bodies, so this is likely why it is omitted. This is not really true though, as the spec does not forbid and it is just considered undefined behavior while most web servers just handle it right (See the note at the top of https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET). All other endpoints are fine, I was just unlucky to select a GET endpoint when I quickly tested it (or rather lucky because this way I found the problem).
So we could change this to only move the parameters in case it is not a GET or DELETE operation, but that won't solve the serialization problems that are the driving force behind this PR. I would vote for ignoring this as the changes are required to send valid requests in quite a few cases and the "forbidden" part is not our problem but rather a different interpretation of the spec which is not correct IMO. I would also go and change this in the stoplight/elements library we use in ocs_api_viewer to make this work for us.

@come-nc @nickvergessen what do you think?

[nickvergessen]

Sounds okay.

[come-nc]

So we could change this to only move the parameters in case it is not a GET or DELETE operation, but that won't solve the serialization problems that are the driving force behind this PR. I would vote for ignoring this as the changes are required to send valid requests in quite a few cases and the "forbidden" part is not our problem but rather a different interpretation of the spec which is not correct IMO. I would also go and change this in the stoplight/elements library we use in ocs_api_viewer to make this work for us.

I’m fine with both solutions, either putting parameters into body only for non-GET requests, or for all of them.
It’s more common to have complex parameters for POST/PUT I suppose, but a GET on a search endpoint might have complex objects for the filter for instance.

[provokateurin]

@nickvergessen do you want to do a final review or can I go ahead and merge?

[nickvergessen]

Go ahead, still having more than 700 unread emails and this is not a prio for me atm.