Caching date makes sense under certain conditions:
- Working on an older set of data still makes sense. Imagine banks performing buying/selling operations on old market data!
- Make the user aware of the fact that he is working with older data. I would add an indicator to the application that supplies a hint "You are currently working on an older set of data."
You'll have to decide whether you want to cache the data on the application of network level.
On the application level means less work for you but only works reliably if the feed refreshes often and there is a good chance you can grab a valid feed within a couple of minutes).
The usual pattern of accessing the data is probably in a similar fashion to:
Download -> Parse -> Validate -> Use in business logic
These steps should be encapsulated in different classes, invisible to the business logic. It simple asks some class to "provide data please".
You can use this to your advantage by adding a "caching"
I would add the following step:
Download -> Parse -> Validate -> Store -> Use in business logic
By store I mean save whatever data you have after the validation (that may either be a raw string or some deserialized classes) to some kind of abstract data storage (different implementations possible, db, file, memory). This is basically an application of the decorator pattern.
You can also create a simple web server that acts as a proxy. On each request the server tries to get a version from the remote source and performs the parsing and validation of its contents. If that is valid it replaces the contents of its current cache and returns the cache to your application.
To reduce the amount of change to your application I would make the proxying server behave in the same way as the remote server. Though, you might want to add an attribute to the returned feed indicating that it is cached (to display that in your application). It should not take a seasoned developer too much time to do this.