Создавать новый объект retrofit'а для каждого запроса - это дичь. В крайне специфических случаях может понадобится иметь возможность пересоздать его - например, при работе с двумя сетями (4G и WiFi) одновременно. Минусы - ретрофит работает через рефлексию, так что сборка объекта занимает значительное время, иногда сопоставимое с временем исполнения запроса, и кушает процессор. И порождает работу для сборщика мусора. А самое главное - не несёт никакого полезного смысла.

Плюсую. Ну вообще, норм тема обойти это - написать синглтон, который будет создавать инстанс апишки ретрофита + кэшировать в array list и в следующий раз брать из него.

Зачем его кешировать? Создал в конструкторе и не трогаешь.

Чтобы не носить все эти апишки с собой?

Все? Она же одна

Именно

15~25

Каких проблем я избегаю когда создаю единый обработчик сети (singleton retrofit)?
Всегда создавал единую точку для взаимодействия с сетью, но при поддержке встречал и другие реализации, где при общении с сетью на каждый запрос создавался свой экземпляр взаимодействия с сетью. Чем такой подход череват и какие проблемы он порождает?

По какому принципу вы разделяете api-методы? (Впервые о таком слышу)

На самом деле, делят как удобно - авторизованная и не авторизованная зона или, к примеру, логически связанные апи - к примеру какая-то фича.

И тебя за это не расстреляли на ревью?

И тебя за это не расстреляли на ревью?

Файл из 60 строчек у кого то считается ужасом? )

Файл из 60 строчек у кого то считается ужасом? )