You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Complex applications (e.g. SBO) in some cases require fetching a lot of interconnected data from KG either by using SPARQL queries or sets of subsequent calls to ES/resource/file endpoints. Such operations might be slow which leads to degraded user experience.
Describe the solution you'd like.
Web clients these days support Cache API which, in the context of SBO, can be efficiently used to cache resources/files with fixed revisions, but requires VARY header (the spec, some pretty good article) to be present on the HTTP responses in order for key matching algorithm to function properly.
I think that a minimal solution would be to have a Vary: Accept header for Resources/Files fetch endpoints, so that clients can discriminate between requests for a file or its metadata, a resource or it's Web representation/redirect (when using Accept: text/html request header).
This will not only enable efficient caching on the client side, improving the UX, but as a side-effect will lower the amount of requests to KG.
An alternative solution would be to implement a custom key matching algorithm on the front-end with a config defining the list of headers that might impact the form of response, but this is less efficient and also requires keeping in tight sync with subsequent KG API changes (If out of sync - wrong content might be served to the client, I suspect this can be also tricky to detect/debug).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Complex applications (e.g. SBO) in some cases require fetching a lot of interconnected data from KG either by using SPARQL queries or sets of subsequent calls to ES/resource/file endpoints. Such operations might be slow which leads to degraded user experience.
Describe the solution you'd like.
Web clients these days support Cache API which, in the context of SBO, can be efficiently used to cache resources/files with fixed revisions, but requires VARY header (the spec, some pretty good article) to be present on the HTTP responses in order for key matching algorithm to function properly.
I think that a minimal solution would be to have a
Vary: Accept
header for Resources/Files fetch endpoints, so that clients can discriminate between requests for a file or its metadata, a resource or it's Web representation/redirect (when usingAccept: text/html
request header).This will not only enable efficient caching on the client side, improving the UX, but as a side-effect will lower the amount of requests to KG.
An alternative solution would be to implement a custom key matching algorithm on the front-end with a config defining the list of headers that might impact the form of response, but this is less efficient and also requires keeping in tight sync with subsequent KG API changes (If out of sync - wrong content might be served to the client, I suspect this can be also tricky to detect/debug).
The text was updated successfully, but these errors were encountered: