Инверсия зависимости от HttpClient

[Anton3]

Цель HttpClient должна быть - не описать самый крутой интерфейс HTTP-клиента, подходящий для любых целей (здесь нам не догнать существующих гигантов), а описать минимальный интерфейс, который нужен для работы ВК-клиента. Так же, как в Java VK API интерфейс TransportClient - минимальный интерфейс, который не претендует на общезначимость.

interface TransportClient {
    fun get(String url): ClientResponse
    fun post(String url, String body): ClientResponse
    fun post(String url, String fileName, File file): ClientResponse
    fun post(String url, String body, String contentType): ClientResponse
    fun get(String url, String contentType): ClientResponse
    fun post(String url): ClientResponse
    fun delete(String url): ClientResponse
    fun delete(String url, String body): ClientResponse
    fun delete(String url, String body, String contentType): ClientResponse
}

Можно взять его и добавить везде suspend. Такой интерфейс реализовать намного проще, чем тот, который сейчас лежит в common-http-client. Далее, HttpClient нужно переименовать во что-нибудь, ясно выражающее узкую специализацию. Сам интерфейс должен переехать в kotlin-vk-api, а вот его тривиальная реализация на Jre должна остаться в common-http-client.

[alatushkin]

Пока не совсем понимаю в чем именно будет выигрыш от такого изменения интерфейса + в чем такая реализация "намного проще".

При этом интерфейс в том виде в котором есть сейчас - допускает добавление нового поведение через компактную функциональную композицию. Причем делать это не затрагивая каждую конкретную реализацию клиента (код которой уже "протестирован") + не зашумляя его при чтении.
Хитрое логгирование, тротлинг, политика ретраев и таймаутов, которую не надо повторно реализовывать в каждом клиенте, кеширование - всё это гораздо компактнее реализуется когда интерфейс допускает функциональную композицию. VkMethodExecuter устроен аналогично по тем же причинам.
И чтобы отказаться от этого удобного подхода нужна веская причина.