Mining Google Web Services: Building Applications with the Google API
Reliable application performance is essential if you plan to use Google Web Services for any type of business purpose. The "Buffering the Data" section explains how buffering affects reliability and therefore application performance. This section considers reliability from a user perspective.
Most people associate reliability with availability, but that's only part of the picture. When working with Google Web Services, you need to consider four reliability factors.
Availability of Data Unless a user can access the Google data, using the application you create is useless. Fortunately, Google Web Services has a high availability rate, so most desktop applications will run fine even if you don't include backup data through a database. However, you need some form of local and/or remote database support for mobile applications where high availability is a requirement and a connection isn't always available.
Consistency of Results Providing consistent results to application users is important. Consistency means including all data (or a standard response to all data outputs). Sometimes, Google won't provide an output that you need. For example, many links won't provide a directory category list (the <directoryCategories> element). If you feel that this information is important, you'll have to find an alternative means of providing the directory category list when the Web site doesn't. Consistency also means providing similar response times (when possible) and standard error notifications.
Accessibility of Google Site You have to decide, at some point, whether you can tolerate any availability problems with Google Web Services because they'll eventually occur. On the day I wrote this information, my ISP experienced connection problems due to an overzealous road crew. Even though Google was probably accessible to someone, it wasn't available to me. To provide maximum reliability, you must provide a cache of some sort . In my case, I had a database full of searches that I'd performed over the last few days. No, it didn't have everything I needed, but at least I had some resources. However, this requirement doesn't always mean creating a database to hold the data, although that is one option. You can also use memory caches or disk-based browser caches. For that matter, your application can rely on the cache provided by a proxy server. The point is to provide some alternative, if you need it, for the few times that Google Web Services doesn't respond.
Availability of the Local Application Strange things can happen to an application between the time it leaves your development machine and when it appears on the user's machine. In general, you need to perform complete application testing on several (more is better) user machines that don't include all the features of your development machine. Make sure you test obscure as well as common features. For example, test every search type that your application supports. It's also important to test features such as the use of cached pages. Make sure you verify that the cached page feature works as needed so that the user doesn't have to wrestle with your application to get the desired results.