A more interesting usage for such a filter which doesn’t change any of the request or response is in a logging scenario. In the code below, before sending the request to the next element in the chain the filter saves the request method and URI, and when it receives the response it logs it with the values captured before. One thing to notice here is that if the HTTP response is not a successful one (i.e., status code 2xx), the ‘error’ parameter passed to the callback will still be null. Filters act at the request / response level, without looking at their semantics at this point.
One more bit of information: the request object will typically contain four properties: ‘type’ (the HTTP method), ‘url’ (the request URL), ‘data’ (the request body, as a string) and ‘headers’ (the HTTP headers which will be sent). The response object is basically the XMLHttpRequest object (both in the WinStore and in the HTML/JS versions) which is used to make the call. That object contains properties / methods which can be accessed to retrieve the response status code, headers and body.
Each filter implementation receives a function ‘next’ which the filter can call to pass the request along, but it doesn’t really need to do that. It can invoke the callback directly, which will effectively bypass the network and send a response to the client directly. One usage of this which I’ve seen and used in other projects (not with Azure Mobile Services, though, at least not yet) is to simulate occasional failures to make sure that the client handles them correctly. I first saw this idea in a Jeff Atwood’s post about what he called the “chaos monkey”, which would insert random failures at different points in a system (apparently this originated from the Netflix engineering team, to explain how they dealt with AWS failures). This is a good scenario where a filter would work – if we add such a filter to our client, we can make it randomly return errors, and this will be applied to all operations (tables and APIs) initiated from the client.
There are other scenarios where bypassing the networking would be a good idea, such as mocking the network responses even for “positive” cases, where you want to test the client in isolation from the service, and can “play” the responses from any custom scripts you have in the server.
Another scenario in which a filter is useful is when we’re caching authentication tokens after a successful login. When a mobile service client logs in to a service, the authentication token which it receives in response to the login operation is valid for a certain number of days (30, if I remember correctly). That means that we can reuse the same token for some time, without having the user log in again (if you need to access the authentication provider API, it’s possible that the credentials stored inside the mobile services token will expire, requiring another login, but I won’t go into the details here).
A filter is a good candidate for implementing this logic. Since it applies to all requests from the client, whenever it gets a 401 response, it can try to login again and then retry the original request, adding the correct authentication header so that the second time the authentication should succeed.
Just a big warning before anyone thinks about using this code: the mobile services token is stored in the client unencrypted. This is bad for obvious reasons. I used this for simplicity sake of this scenario (I wanted to focus on the revalidation itself), but for real applications you should definitely use some secure storage, such as the Credential Locker for Windows Store / JS applications.