Ask HN: Client Side Caching Strategies?

I'm designing the interaction between our API and web client. The two strategies I've come up with are:

1. A dumb API, which exposes objects pulled from the DB and results of server side calculations. The client can cache the data itself, so that future requests can be built from the cached data instead of an API call. The downsides are that more initial requests might be required to grab different datasets and the client has construct the requested data into a meaningful structure that the view can consume. It also provides less opportunity to optimize individual API requests on the server, and perhaps there'd be some code duplication between the client and server. The cached data would be relatively unstructured (lists of requested objects, segregated by type).

    API -> get all states
    API -> get all farms
    Client -> combine the two into a list of Apple Farms by State
    Client -> combine the two into a list of # of Farms in each State

2. A smart API, which aims to answer questions asked by the client. The client can cache specific requests but could not use the request data to build other requests from the cache because data might be missing. However the server can optimize DB queries and provide structured data. The cached data would be request results indexed by the API request parameters.

    API -> get all Apple Farms by State
    API -> get # of Farms in each State

We have a lot of base data that makes sense to request en-mass and cache locally (Strategy 1). We also have some more specific data based on the results of user interaction, which would benefit most from the optimized queries that Strategy 2 provides. In both cases we'd store the cache using local storage so it can persist across page loads. A combination of the two is possible, but is more work and increases complexity.

I'd love some comments on each strategy, and any articles or personal experience about client side caching of API data.