Support GET API focused on Mobile about featurehub HOT 4 CLOSED

thinking the return type would be a map<sdkUrl,List> where the list is only updated features. What do you think @chrusty ?

from featurehub.

I could imagine an API call that just returns the entire list of features (same payload as you get with the SSE API upon connection / reconnection). Certainly this was my assumption on how the API would work initially!

To me it doesn't make any difference in terms of bandwidth if a user polls for 10 features every 30 seconds or reconnects every 30s to the SSE endpoint to get the same 10 features. The one problem we'd have would be a lack of control over how frequently the user polls the GET endpoint. In our own SDKs we could of course control this, but our own SDKs would be using SSE anyway.

Perhaps some simple rate-limiting middleware if this becomes an issue, but for now probably just keep it simple.

from featurehub.

@chrusty do you think given it wouldn't be cached anyway, we shouldn't turn it into a POST API then? I'm thinking for feature strategies this would allow the server to evaluate settings as well.

from featurehub.

@rvowles now that I have the background on this, I think the solution could be to have two endpoints:

• GET /features could return the entire list of features including their strategies, and leave the interpretation up to the client
• POST /features would take a bunch of information in the request (client version, OS, random ID etc), and return a pre-interpreted list of features which the client would then blindly apply

from featurehub.