https://gist.github.com/swankjesse/8571a8207a5815cca1fb

Whoa… Well, you're right that it's not safe to change url in Retrofit, but OkHttp interceptor is not a great place for that even more because not only it has the same problem with delayed requests but also you can't understand that request is coming from Retrofit inside of the interceptor (analyzing stacktrace is not an option)… Imagine you also have non-REST requests to the api endpoint that you do through same OkHttp instance without Retrofit.

Would you suggest to rebuild the Retrofit instance with new url and use something like Provider<Retrofit> instead of direct reference to the Retrofit or even rebuild whole graph of network dependencies to change endpoint in the application?

That has always been the recommendation, yes. BaseUrl existed solely for client-side load balancing or geographical proximity specialization of the same semantic host. Since there's no longer an HTTP client abstraction, we no longer need the behavior to exist in Retrofit.

ok, thanks for confirmation.

// Anyway, 👍 👍 for more immutability, though BaseUrl was so convenient for functional testing with mock webserver…

Yep. This new interceptor is the new best way to test with a mock webserver.

in my case baseUrl contains a path segment. I don't see any other way than manually replace the old baseUrl with the new one...
@swankjesse do you know any other way to change the baseUrl (with path) using interceptor mechanism?

@jbaginski you can rewrite the URL however you like. One option is to extract out the path & query in an interceptor, and add those on to the base URL.

thanks @swankjesse, I ended up manipulating a string directly. it's not the best solution but it works ;)

This solution will affect @get (full path) @post (full path) and @url so that they can not work,try my solution: https://github.com/JessYanCoding/RetrofitUrlManager