Convenience features for `NextcloudRequest.Builder`

Issue

The following setup for a NextcloudRequest is quite verbose:

final var parameters = Collections.singleton(new QueryParam("foo", "bar"));
final var nextcloudRequest = new NextcloudRequest.Builder()
    .setMethod("GET")
    .setParameter(parameters)
    .setUrl("/endpoint")
    .build();

Especially for beginners, we should try to minimize the necessary boilerplate code to perform an actual request.

Proposal

Automatically parse QueryParams from the given URL

We could parse the QueryParams from the given URL and add them to our Collection (just as if .setParameter() would have been called). A working sample implementation (in Kotlin) is already in the nextcloud-commons library available.

final var nextcloudRequest = new NextcloudRequest.Builder()
    .setMethod("GET")
    .setParameter(parameters)
    .setUrl("/endpoint?foo=bar")
    .build();

Default method property to GET

It is the most often used HTTP verb and a natural choice to be preset (of course with keeping the possibility to override it):

final var parameters = Collections.singleton(new QueryParam("foo", "bar"));
final var nextcloudRequest = new NextcloudRequest.Builder()
    .setParameter(parameters)
    .setUrl("/endpoint")
    .build();

Looking forward to some opinions 🙂
PS.: This issue has been split out of #266

Commencez par l’implémentation de NextcloudRequest.Builder et examinez comment setUrl, setParameter et la méthode HTTP sont stockés avant build(). Comparez l’analyse d’URL demandée avec l’exemple Kotlin lié, puis vérifiez que les paramètres d’URL sont inclus, que GET est la valeur par défaut et qu’une méthode explicitement sélectionnée fonctionne toujours.