Hide implementation details from library users

[andregasser]

OkHttp3 and Gson leak through the client-side API. Check if really necessary and change if needed. Leaking details to the library users makes it difficult to change implementation details without breaking the API.

[bocops]

For some progress here, I have a patch at https://github.com/bocops/mastodon4j/tree/patch_mastodonclient_1 that changes the GET/DELETE/PATCH/PUT methods in MastodonClient to mostly accept Parameter lists instead of having to expose OkHttp's RequestBody.

Should this be added to main directly, or do we want to have a separate branch for that?

[andregasser]

Hello @bocops, maybe we should start using feature branches for issues in general, and create PR's for merging them into master when they are ready? Would make reviewing code easier, right?

[andregasser]

@bocops : Looking at the MastodonClient.Builder()signature, I think we could also get of the Gson() instance that is passed every time the Builder(...) is called. IMHO, we could remove the Gson parameter entirely from the method signature, as we always pass the same object. I do not think that a library user should ever be able to tinker with the serialization/deserialization logic we're relying on. Do you share that opinion?

[bocops]

Definitely, we shouldn't expose implementation details to users like that, the Gson() instance in each Builder call should be removed and I can deal with that in my upcoming revised PR.

I think we can go one step further. Currently, basically every API method looks like this:

    fun getAccount(accountId: Long): MastodonRequest<Account> {
        return MastodonRequest(
            { client.get("api/v1/accounts/$accountId") },
            { client.getSerializer().fromJson(it, Account::class.java) }
        )
    }

with the Gson instance being exposed via MastodonClient.getSerializer(). It is probably cleaner to change this into something like a call to client.getMastodonRequest(...), which would deal with the necessary serialization in our MastodonClient instead. I would like to do that in a separate PR later, because the one I'm working on already deals with #48 and #49 and would become too massive otherwise.

[andregasser]

Yes, sounds good to me. Classes like Accountsprovide the methods for calling the API endpoints (like now) but deserialization is moved into MastodonClient. Doing so, we can save quite some lines of code I guess. I also see no issues with the reactive implementation, as they just call the non-reactive ones. Yes, let's do this in a separate issue/PR then. Thanks for pointing out! 😀

[bocops]

Reposted the above as separate issue #51.