Is 20 Java classes for just making...
This is entirely the wrong question. Something is wrong or you wouldn't be asking. It sounds like you're looking for something to blame. Anguishing over the number of classes isn't going to fix it.
I've felt this same pain before. You step back and look at everything. It works. You can kinda follow it. But you know looking at it later you're going to be lost. You don't like that. You want to fix it now while you can follow it. Setting a limit on the number of classes because you're just trying to do x isn't going to fix it.
What will fix it is abstraction.
Why do you CARE that there are 20 classes? It may be because they're all showing up in one place so now you have to think about them all at once. That is what's bad.
20 is a big number. 4 and 5 are not. I wouldn't mind seeing 4 groups that each had 5 classes working together. That's still 20. It's just organized so it's easier to look at.
Sometimes a dependency injection framework makes it easy to take a procedural attitude to construction. You just create a pile of links between objects that has no structure to it. It's easy to write. Not so easy to read.
If you've dumped all of them into one file that defines how they link together you're looking at the entire object graph at once. With only 5 classes that can start to be painful. Find some logical separations. Break things down. Group objects together that have to do with each other. Separate those that don't.
A big thing that can help with this is creational patterns. When you expose every dependency an object has, you make building it a nuisance. A good builder lets you separate the dependencies that change often from the dependencies that don't. Rather than hide dependencies in the object you hide them in the builder. When good defaults are available they should be easy to use.
As for interfaces you're saving grace here is you said "almost". I HATE when people blindly extract interfaces without thinking about what they're doing. It's completely backwards to think an interface BELONGS to the class that implements it. No, clients OWN the interface. The interface exists FOR the client, should be defined BY the client, and may not ever change except at the CONSENT of the client. If you happen to be an object that implements that interface, good for you. Now shut up and do what you're told. The client doesn't even want to know you exist.
That said, I LIKE interfaces. Mostly because when I write clients that refer to them and not implementations I'm not tempted to use new on them. The big exception to this is value objects. Strings don't need you creating interfaces for them. If you use other value objects, even ones of your own design, generally you don't give them interfaces, you shouldn't give them behavior, don't really need to test them, and shouldn't ever change them. You know, like strings.
Now if you're talking about a behavior object that has to actually do some thinking then test that damn thing.
If you're doing MVP, setting up dagger components, modules and scopes, you're doing a hell of a lot more than just REST.