Proposal: Check for changes via etag header

[cedWetzel]

Using the fetch functions like fetchElement don't implement the possibility to check the resource state by sending an etag inside the header. This makes it hard to cache and invalidate our resources, requested by the FSXA-API. Tho we can only request the etag to be provided in the response body, this adds unnecessary traffic and complexity instead of relying on standards implemented in the HTT-Protocol.

Proposal: Extend the fetchX-functions to an etag parameter that is passed to the fetch-functions header combined with a If-None-Matchrule. Therefore we need to check the response code (304) and pass a newly introduced return type like CachedResponse that is used by the individual developer OR by adding a universal caching interface, so the caching interface can be called if the response code was 304.

By making the new etag/caching parameter optional, no breaking changes occur.

[nico-mcalley]

Hi @cedWetzel It sounds like a good feature to be added to the fsxa-api and we've created a ticket for that internally (TNG-1248). Thank you for your input.

PS: We also accept pull requests 😉

[nico-mcalley]

After some research on the topic "etags in our fetch methods" we found out that the feature is subject to severe limitations. For example, the resource state of an element with resolved references cannot be determined via a single etag, since each referenced item has its own etag. A similar problem occurs when fetching with a filter, as the individual documents have their own etag and there is no single overarching one.

This means that supporting etags only really works when fetching individual documents - at which point the expected performance improvement is marginal, as the individual JSON documents are typically very small. Due to the above limitations we currently don't think that adding support for etags is worth the effort.

Do you currently have a specific problem that you hope to solve using etags? If so, could you please go into more detail about what it is you are trying to solve and how you expect etags to help you? Maybe we could suggest an alternative approach.

[nico-mcalley]

It seems the issue has timed out. This means we assume that the issue has either already been fixed by the creator of the issue, is no longer reproducible, or the priority of this issue is too low.

@cedWetzel If you have any further questions or suggestions, please feel free to open a new issue or leave a comment.