Issue-6 Support custom interceptors - #7

best to avoid coupling to okhttp3 so I prefer creating our own dedicated Interceptor interface

I see, good point.

I afraid of such a wide access to API protocol, I thought better to add some "safe" AroundAspect like interceptor which will be safe not to break API calls but allow different before/after code parts.

When do you think the aspect oriented flows would be in place? I wonder how it will be implemented.

Maybe meanwhile we can create something simple to allow interceptors but limit them to specific code parts like "beforeCall", "afterCall" you can do by creating dedicated interface and create one general interceptor that run list of such interfaces and let developer use those which will both limit the exposure of internal flows vs give enough abilities to save things or log or etc. WDYT?

I think it is fine, as long as the new interface provides access to the request and response.. if it does not, then this dummy interceptor might be useless. so basically could be an interface like:

public interface Interceptor {

beforeCall(Request);

afterCall(Request, Response);

}

WDYT?

I think we can provide both request and response data we just need to plan what response should contain, for example raw Retrofit response is problematic since you dont know which call adapter is handling it since interceptors happening before call adapter.
So sound like we need to handle "before" inside the interceptor wrapper but response to provide part of SynchronousCallAdapterFactory or StringConverterFactory.

For example I think that those provided "before/after" code injection parts can not manipulate request nor response so both request and response references should be immutable.