Look into caching for our APIs through headers set in Response
Source of request from @cguindon: > Why use hidden when you can comment out the whole section and avoid a call to our API. From what I can tell, using hidden class does not stop the browser from calling our API. > > I am also noticing that this page is making 4 API calls to the same URL which is current not cached by our API. While, I am not asking you to fix this now, I think we could create a tech debt issue in EFSA to optimize this so that we only fetch members once regardless if we have more than 1 widget on the page. To accomplish this, the easiest way would be to add a new ResponseFilter to the SDK project that links with a new annotation to add a predefined set of cache headers. While this solution does require manual updates in our APIs, we have enough exceptions to the rule that handling it manually is the best method currently to make sure we don't incorrectly cache sensitive data. For our caching profiles, do we want to pull the ones we have in NGINX and create equivalents in our APIs, such as `safe`, `aggressive`, and `maximum`? We can configure whatever we like really, as this is going to be added on once we have the actual API response, so we should be able to have some pretty good flexibility.
epic

Copyright © Eclipse Foundation AISBL. All rights reserved.     Privacy Policy | Terms of Use | Copyright Agent