Split a service declaration into multiple interfaces

Question

I am creating an application that associates an API with approximately 265 methods. I would really like to split the declaration of these APIs into several files so that they are organized and accessible. However, Retrofit explicitly prohibits combining interfaces through an extension.

java.lang.IllegalArgumentException: Interface definitions must not extend other interfaces. 

I tried to declare it as follows.

 public interface ApiService extends ProfileService, AccountService { // Empty interface, methods divided into other services } public interface ProfileService { @GET("/api/v1/protected/profile") public void getProfile(Callback<Profile> callback); ... } public interface AccountService { @GET("/api/v1/protected/account") public void getAccount(Callback<Account> callback); ... } 

This issue is discussed with a transfer request. The authors of the library decided that the extension of such interfaces was not in the spirit of the library. https://github.com/square/retrofit/pull/676

Jake Wharton (author) says "Modernization supports composition." And in response to the question "Do you really have one adapter with a ton of proxies?", "Yes, they are generated from the service advertisement in protos. One interface for each service."

I read about the composition against inheritance and do not understand how to achieve the goal of breaking the declaration.

How can I split the interface declaration? Is there any best practice that I am missing?

Thanks.

Answer 1

Just create separate interfaces.

 public interface ProfileService { /* ... */ } public interface AccountService { /* ... */ } ProfileService profileService = mRestAdapter.create(ProfileService.class); AccountService accountService = mRestAdapter.create(AccountService.class); 

Answer 2

I am still experimenting if this is the best way to use this, but here is what I still have. This may not be the cleanest approach, but I like it compared to one service with 100 api calls. Breaks it up a bit and makes reading easier.

This is the main class for accessing data. I saw many separate two static methods that I have in a separate class, but I just included it as one.

 public class RetrofitApi { public enum ApiTypes { USER_API(UserApi.class); private final Class<? extends RetrofitApi> apiClass; ApiTypes(Class<? extends RetrofitApi> apiClass){ this.apiClass = apiClass; } Class<? extends RetrofitApi> getApiType() {return this.apiClass;} } public static <T> T getApi(RetrofitApi.ApiTypes type) { try { return (T) type.getApiType().newInstance(); } catch (InstantiationException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } return null; } public static RestAdapter getRestAdapter() { RestAdapter restAdapter = new RestAdapter.Builder() .setEndpoint(BASE_URL) .setLogLevel(retrofit.RestAdapter.LogLevel.HEADERS) .build(); return restAdapter; } } 

Each service has its own api. This means more classes. I divided them into api, service, model. An API is a high level that you will use and disclose. A service is more or less just a call list. Model - model (data object).

 public class UserApi extends RetrofitApi { private UserService service; public UserApi() { RestAdapter restAdapter = RetrofitApi.getRestAdapter(); service = restAdapter.create(UserService.class); } public void login(String email, String password, Callback<User> callback) { service.login(email, password, callback); } } 

Service is an interface. Its more or less just a list of called api calls.

 public interface UserService { @GET("/api/users/login") void login(@Query("email") String email, @Query("password") String password, Callback<User> callback); } 

Then use it.

  UserApi api = RetrofitApi.getApi(RetrofitApi.ApiTypes.USER_API); api.login(email,password,callback); 

And here is the structure of the project. For me it seems clean at the moment. I am sure that it will become big when I have 20+ of them. But it can be a little cleaner if the 20 have several challenges.