Very early this year, I posted about request behaviors. These simple objects can help you factor out small bits of reused UI, persistence, and validation code related to your network. If you haven’t read the post, it lays the groundwork for this post.
Request behaviors are objects that can exceute arbitrary code at various points during some request’s execution: before sending, after success, and after failure. They also contain hooks to add any necessary headers and arbitrarily modify the URL request. If you come from the server world, you can think of request behaviors as sort of reverse middleware. It’s a simple pattern, but there are lots of very powerful behaviors that can be built on top of them.
In the original post, I proposed 3 behaviors, that because of their access to some piece of global state, were particularly hard to test: BackgroundTaskBehavior, NetworkActivityIndicatorBehavior, AuthTokenHeaderBehavior. Those are useful behaviors, but in this post, I want to show a few more maybe less obvious behaviors that I’ve used across a few apps.
API Verification
One of the apps where I’ve employed this pattern needs a very special behavior. It relies on receiving 2XX status codes from sync API requests. When a request returns a 200, it assumes that sync request was successfully executed, and it can remove it from the queue.
The problem is that sometimes, captive portals, like those used at hotels or at coffee shops, will often redirect any request to their special login page, which returns a 200. There are a few ways to handle this, but the solution we opted for was to send a special header that the server would turn around and return completely unmodified. No returned header? Probably a captive portal or some other tomfoolery. To implement this, the server used a very straightforward middleware, and the client needed some code to handle it as well. Perfect for a request behavior.
class APIVerificationBehavior: RequestBehavior {
let nonce = UUID().uuidString
var additionalHeaders: [String: String] {
return ["X-API-Nonce": nonce]
}
func afterSuccess(response: AnyResponse) throws {
guard let returnedNonce = response.httpResponse.httpHeaderFields["X-API-Nonce"],
returnedNonce == nonce {
throw APIError(message: "Sync request intercepted.")
}
}
}
It requires a small change: making the afterSuccess method a throwing method. This lets the request behavior check conditions and fail the request if they’re not met, and it’s a straightforward compiler-driven change. Also, because the request behavior architecture is so testable, making changes like this to the network code can be reliably tested, making changes much easier.
OAuth Behavior
Beacon relies on Twitter, which uses OAuth for authentication and user identification. At the time I wrote the code, none of the Swift OAuth libraries worked correctly on Linux, so there was a process of extracting, refactoring, and, for some components, rewriting the libraries to make them work right. While I was working on this, I was hoping to test out one of the reasons I wanted to created request behaviors in the first place: to decouple the authentication protocol (OAuth, in this case) from the data that any given request requires. You should be able to transparently add OAuth to a request without having to modify the request struct or the network client at all.
Extracting the code to generate the OAuth signature was a decent amount of work. Debugging in particular is hard for OAuth, and I recommend this page on Twitter’s API docs which walks you through the whole process and shows you what your data should look like at each step. (I hope this link doesn’t just break when Twitter inevitably changes its documentation format.) I also added tests for each step, so that if anything failed, it would be obvious which steps succeeded and which steps failed.
Once you have something to generate the OAuth signature (called OAuthSignatureGenerator here), the request behavior for adding OAuth to a request turns out to not be so bad.
struct Credentials {
let key: String
let secret: String
}
class OAuthRequestBehavior: RequestBehavior {
var consumerCredentials: Credentials
var credentials: Credentials
init(consumerCredentials: Credentials, credentials: Credentials) {
self.consumerCredentials = consumerCredentials
self.credentials = credentials
}
func modify(request: URLRequest) -> URLRequest {
let generator = OAuthSignatureGenerator(consumerCredentials: consumerCredentials, credentials: credentials, request: request)
var mutableRequest = request
mutableRequest.setValue(generator.authorizationHeader, forHTTPHeaderField: "Authorization")
return mutableRequest
}
}
Using modify(request:) to perform some mutation of the request, we can add the header for the OAuth signature from OAuthSignatureGenerator. Digging into the nitty-gritty of OAuth is a out of the scope of this post, but you can find the code for the signature generator here. The only thing of note is that this code relies on Vapor’s SHA1 and base 64 encoding, which you’ll have to swap out for implementations more friendly to your particular environment.
When it’s time to use the use this behavior to create a client, you can create a client specific to the Twitter API, and then you’re good to go:
let twitterClient = NetworkClient(
configuration: RequestConfiguration(
baseURLString: "https://api.twitter.com/1.1/",
defaultRequestBehavior: oAuthBehavior
)
)
Persistence
I also explored saving things to Core Data via request behaviors, without having to trouble the code that sends the request with that responsibility. This was another promise of the request behavior pattern: if you could write reusable and parameterizable behaviors for saving things to Core Data, you could cut down on a lot of boilerplate.
However, when implementing this, we ran into a wrinkle. Each request needs to finish saving to Core Data before the request’s promise is fulfilled. However, the current afterSuccess(result:) and afterFailure(error:) methods are synchronous and called on the main thread. Saving lots of data to Core Data can take seconds, during which time the UI can’t be locked up. We need to change these methods to allow asynchronous work. If we define a function that takes a Promise and returns a Promise, we can completely subsume three methods: beforeSend, afterSuccess, afterFailure.
func handleRequest(promise: Promise<AnyResponse>) -> Promise<AnyResponse> {
// before request
return promise
.then({ response in
// after success
})
.catch({ error in
// after failure
})
}
Now, we can do asynchronous work when the request succeeds or fails, and we can also cause a succeeding to request to fail if some condition isn’t met (like in the first example in this post) by throwing from the then block.
Core Data architecture varies greatly from app to app, and I’m not here to prescribe any particular pattern. In this case, we have a foreground context (for reading) and background context (for writing). We wanted simplify the creation of a Core Data request behavior; all you should have to provide is a context and a method that will be performed by that context. Building a protocol around that, we ended up with something like this:
protocol CoreDataRequestBehavior: RequestBehavior {
var context: NSManagedObjectContext { get }
func performBeforeSave(in context: NSManagedObjectContext, withResponse response: AnyResponse) throws
}
And that protocol is extended to provide a handle all of the boilerplate mapping to and from the Promise:
extension CoreDataRequestBehavior {
func handleRequest(promise: Promise<AnyResponse>) -> Promise<AnyResponse> {
return promise.then({ response in
return Promise<AnyResponse>(work: { fulfill, reject in
self.context.perform({
do {
try self.performBeforeSave(in: context, withResponse: response)
try context.save()
fulfill(response)
} catch let error {
reject(error)
}
})
})
})
}
}
Creating a type that conforms to CoreDataRequestBehavior means that you provide a context and a function to modify that context before saving, and that function will be called on the right thread, will delay the completion of the request until the work in the Core Data context is completed. As an added bonus, performBeforeSave is a throwing function, so it’ll handle errors for you by failing the request.
On top of CoreDataRequestBehavior you can build more complex behaviors, such as a behavior that is parameterized on a managed object type and can save an array of objects of that type to Core Data.
Request behaviors provide the hooks to attach complex behavior to a request. Any side effect that needs to happen during a network request is a great candidate for a request behavior. (If these side effects occur for more than one request, all the better.) These three examples highlight more advanced usage of request behaviors.
