Change apiEndpoint

[ps-feng]

Hi,

It would be nice to be able to change the apiEndpoint from XingApi in runtime. Seems it should be possible by just providing a setter, which would set the new endpoint and invalidate the resource cache?

[serj-lotutovici]

This is possible, but it's error prone. To do this right we would also have to implement a message dispatch mechanism that would notify all running resources/specs with the previous endpoint to stop. There's is quite some machinery already dependant on the fact that the API client is immutable that would require a change in the line internals.

Don't know if this is worth the cost of easier debugging. But not completely against it.

[ps-feng]

Good point. What if we pass some kind of BaseUrl object to the CallSpec's builder? This BaseUrl instance would be held by XingApi and we would be able to change it dynamically, applying to all the CallSpecs? In RealCallSpec builder.request() is called each time a request if being made, it could get the base url at that moment.

[serj-lotutovici]

Gave this a deeper thought, and found a few issue that we should take into account before we proceed.
If you use a different endpoint it usually also means different application identification, for example consumer key and consumer secret (may be more). If you are building the api client as XingApi.Builder#oauth1() you will also have to change this when you change the url.

Another possibility would be to expose a BaseUrl and allow to set it only via XingApi.Builder#custom() but still you leave you're self in a position, when you have to change the custom signing and so on.

@dhartwich1991 what's your opinion on this?

[cmonfortep]

Hi guys,

For the baseUrl or anything else that we want to be able to change in runtime, even if the request has been enqueued, I think a good approach is being able to set to XingApi any class where we can implement a method that it will be called before executing the request.

This concept is very similar to interceptors (we use interceptors in our project to manage tokens) check this class to know more.

An example of changing a url in runtime with retrofit, can be found here.

Well...thinking this better, currently we have 2 scenarios:

• Changing the base url for some request (some endpoints in our api have different baseUrls): In this case we know the base url when we are creating the request, but we don't need to change any token. So I think an interceptor is not a good option here. Maybe overriding a method or being able to set the baseurl, for that request only, is better.
• Changing the base url for the whole xing api (xingBoxes). In this case, to create a new xingapi is needed, because as @serj-lotutovici said, tokens will change too.