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
Add support for ETags, which provide a way for applications to verify if a given endpoint still returns the last cached data. This reduces load and bandwidth
With every fetch from the AH-API, the server could generate a hash like MD5 and response with the ETag Header which holds the value of the hash.
A client can take this value and use it in the If-None-Match header. If the hash is still the same, because AH-API data is still the same or the next request from the client has been done before a new fetch occured, the Server answers with a 304 - Not Modified response without body, and with the normal response body, if the data has been changed.
This reduces the bandwidth needed and would be a nice addition, please ask if I explained something bad or if there still are questions
The text was updated successfully, but these errors were encountered:
Add support for ETags, which provide a way for applications to verify if a given endpoint still returns the last cached data. This reduces load and bandwidth
With every fetch from the AH-API, the server could generate a hash like MD5 and response with the
ETag
Header which holds the value of the hash.A client can take this value and use it in the
If-None-Match
header. If the hash is still the same, because AH-API data is still the same or the next request from the client has been done before a new fetch occured, the Server answers with a304 - Not Modified
response without body, and with the normal response body, if the data has been changed.This reduces the bandwidth needed and would be a nice addition, please ask if I explained something bad or if there still are questions
The text was updated successfully, but these errors were encountered: