I am using ReactiveCocoa in an app which makes calls to remote web APIs. But before any thing can be retrieved from a given API host, the app must provide the user's credentials and retrieve an API token, which is then used to sign subsequent requests.
I want to abstract away this authentication process so that it happens automatically whenever I make an API call. Assume I have an API client class that contains the user's credentials.
// getThing returns RACSignal yielding the data returned by GET /thing.
// if the apiClient instance doesn't already have a token, it must
// retrieve one before calling GET /thing
RAC(self.thing) = [apiClient getThing];
How can I use ReactiveCocoa to transparently cause the first (and only the first) request to an API to retrieve and, as a side effect, safely store an API token before any subsequent requests are made?
It is also a requirement that I can use combineLatest:
(or similar) to kick off multiple simultaneous requests and that they will all implicitly wait for the token to be retrieved.
RAC(self.tupleOfThisAndThat) = [RACSignal combineLatest:@[ [apiClient getThis], [apiClient getThat]]];
Further, if the retrieve-token request is already in flight when an API call is made, that API call must wait until the retrieve-token request has completed.
My partial solution follows:
The basic pattern is going to be to use flattenMap:
to map a signal which yields the token to a signal that, given the token, performs the desired request and yields the result of the API call.
Assuming some convenient extensions to NSURLRequest
:
- (RACSignal *)requestSignalWithURLRequest:(NSURLRequest *)urlRequest {
if ([urlRequest isSignedWithAToken])
return [self performURLRequest:urlRequest];
return [[self getToken] flattenMap:^ RACSignal * (id token) {
NSURLRequest *signedRequest = [urlRequest signedRequestWithToken:token];
assert([urlRequest isSignedWithAToken]);
return [self requestSignalWithURLRequest:signedRequest];
}
}
Now consider the subscription implementation of -getToken
.
- In the trivial case, when the token has already been retrieved, the subscription yields the token immediately.
- If the token has not been retrieved, the subscription defers to an authentication API call which returns the token.
- If the authentication API call is in flight, it should be safe to add another observer without causing the authentication API call to be repeated over the wire.
However I'm not sure how to do this. Also, how and where to safely store the token? Some kind of persistent/repeatable signal?
Thinking about token will expire later and we have to refresh it.
I store token in a MutableProperty, and used a lock to prevent multiple expired request to refresh the token, once the token is gained or refreshed, just request again with new token.
For the first few requests, since there's no token, request signal will flatMap to error, and thus trigger refreshAT, meanwhile we do not have refreshToken, thus trigger refreshRT, and set both at and rt in the final step.
here's full code
How about
To be sure, this solution is functional identical to Justin's answer above. Basically we take advantage of the fact that convenience method already exists in
RACSignal
's public API :)So, there are two major things going on here:
-getToken
to get the same values no matter what.In order to share side effects (#1 above), we'll use RACMulticastConnection. Like the documentation says:
Let's add one of those as a private property on the API client class:
Now, this will solve the case of N current subscribers that all need the same future result (API calls waiting on the request token being in-flight), but we still need something else to ensure that future subscribers get the same result (the already-fetched token), no matter when they subscribe.
This is what RACReplaySubject is for:
To tie these two concepts together, we can use RACSignal's -multicast: method, which turns a normal signal into a connection by using a specific kind of subject.
We can hook up most of the behaviors at initialization time:
Then, we implement
-getToken
to trigger the fetch lazily:Afterwards, anything that subscribes to the result of
-getToken
(like-requestSignalWithURLRequest:
) will get the token if it hasn't been fetched yet, start fetching it if necessary, or wait for an in-flight request if there is one.