There is an article about a rate limit change that can impact client side application even after an application check. How can the application be optimized to get under the limit?
The question now becomes, how can the calls made to eBay be reduced? Depending on your application, you may be able to make use of a light weight server.
Please look at the diagram below. This shows how a light weight server (LWS) could augment a client side application with a central caching mechanism. Here is the basic outline:
The LWS inspects or collects a list of caching targets
The LWS gets copies of those targets from eBay every 30 minutes
Clients request a list of caching targets from the LWS when it initializes (GetCacheList)
Clients inspect their new requests for matches to the cache list
a. On a match, the client calls out to the LWS for results (GetCache)
b. No match, the client calls out to eBay APIs directly
Here is a finding example:
LWS makes calls to FindPopularSearches (shopping) to build a list on startup.
LWS starts calling findItemsByKeywords (finding) to fill it cache from the list
Client gets a cache list from LWS
User enters a search that matches an item in the cache list (ipod)
Client makes a request to LWS to get the cached copy
LWS maintains the cache every 30 minutes
The general idea is to get the LWS handling all the most common requests so that maybe a few hundred calls for the same request from all the clients in 30 minutes would collapse down to one. Yes, the applications will want to manage the content of the API results for expired items.
The key part is picking the list to cache and how to get the list to the clients. For the latter, they could call the LWS and get a list on initialization or on some schedule. How is the initial list populated on the LWS? This can depend on your application. Here are a few suggestions: