Perhaps this is a stupid question, but I have not yet found a clear answer.
My server handles ETag caching for some fairly large JSON responses that we have, returning 304 NOT MODIFIEDwith an empty body if the header If-None-Matchcontains the same hash as the new one generated (shallow ETags).
Is it supposed that browsers should handle this automatically, or client applications in the browser that consume APIs must asynchronously implement some logic to handle such responses (for example, use the cached version if it responds 304, create / update the cached version otherwise)?
Because so far I have manually implemented this logical client side, but I wonder if I just invented the square wheel ...
In other words, for example, with a heading Cache-Control, client applications in the browser do not need to analyze the value, for example, check for max-age, somehow store it, set the timeout, etc.: directly in front of the browsers. The question is, should browsers behave the same when they receive 304?
Here is how I wrote my client so far (built using AngularJS, working in browsers):
myModule
.factory("MyRepository", ($http) => {
return {
fetch: (etag) => {
return $http.get(
"/api/endpoint",
etag ? { headers: { "If-None-Match": etag } } : undefined
);
}
};
})
.factory("MyService", (MyRepository, $q) => {
let latestEtag = null;
let latestVersion = null;
return {
fetch: () => {
return MyRepository
.fetch(latestEtag)
.then((response) => {
latestEtag = response.headers("ETag");
latestVersion = response.data;
return angular.copy(latestVersion);
})
.catch((response) => {
return 304 === error.status
? angular.copy(latestVersion)
: $q.reject(response)
});
}
};
});
So basically, is this logic needed above, or should I just use it $http.get("/api/endpoint")directly?
, , , , , "" .