We are planning to build a web application which will consume data from an internal REST API that centralizes all of our "core" business data. For matter of demonstration, let's say this API exposes data for a very large Products database. So an example of our web application using the API would be:
A View that lists all products and the user can add products to his "wish list". (Very silly example)
Now, the difficulty is: each time we would have to know about a user products, we would need to send a request to the API to get the products names and other data, since we would only save its Id internally. This is okay in this simple example, but there will be cases much more complex than this (Reports, for instance) and it just seems very wrong to always fetch data from the API. So we came up with several approaches:
1 - Fetch the products from the API on views that create records and save then internally in our database. The other areas that uses the products, would query it from our Database not from the API.
2 - Some sort of caching strategy. But where? Who would be the responsible for the caching? The API or the client? If so, what strategies would better suit this case?
Case 1 sounds like an plausible solution but it would create a problem of synchronization. We would need to check often to see if changes were made (its name, for instance).
Case 2 sounds like a good one but I personally never have seen a similar architecture before nor had implemented one.
Another thing that came up was, If we only save the Id's in our local db, then when we need to "build" the view with all the data, we would need to query our local db getting all the ids of the user products, send a request to the API to get the products. The problem? The API doesn't know about the relationship between user -> products so we would need to query all products and somehow merge the data in our side.
Any kind of advice, shared experience or basically any input would be much appreciated.
PS1: Both the API and the Web app are written in C#.
PS2: When I said "Internal API" in the question, I meant that it is an API designed by our team. The external in the title means that the API will be separated from our web app, acting like an external resource.