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
Current _embedded handling put embedded resources in cache. This causes several issues
The first one is that when using NeverCache, if you follow Ketting's guidelines and use follow/followAll to get embedded resources, you'll end up with n additional HTTP requests performed, defeating the whole purpose of embedding. Moreover, those fetches will return you the representation available on self-link, which might be totally different from what you expect, as the spec states:
Embedded Resources MAY be a full, partial, or inconsistent version of the representation served from the target URI.
The alternative is to use getEmbedded, but there's a scary warning and results might here again not be as expected (since a subsequent fetch without embedded resources would wipe them out). Moreover, even when using getEmbedded, you cannot filter which embedded you'll get back since there's no rel filtering.
In its current current approach, it looks very hard to use embedded properly when using ketting. The issues looks related to cache handling but there's no way to disable caching (NeverCache is not a switch-off per se).
The text was updated successfully, but these errors were encountered:
hey @beuss , does ShortCache works for you? NeverCache only really exists for niche cases like testing.
If not, i would be interested to understand your use-case better. It's true that the link embedded resource can disappear if we got a whole new representation of that resource that no longer embeds them, but if you have a previous State, that state is supposed to be mostly immutable.
Well ShortCache may adds other issues :)
If embedded is not the same representation as the self endpoint, you end up poisoning it. Let say you've a customer representation where you embedded address summary (let's say zipcode and city only) to display it on level 0 form, its self-link will be say /address/1.
From this form you offer a link to edit the address, it fetches /address/1, but if user clicks too fast you hit cache and get the partial representation (from previous embedded)
Current _embedded handling put embedded resources in cache. This causes several issues
The first one is that when using
NeverCache
, if you follow Ketting's guidelines and usefollow
/followAll
to get embedded resources, you'll end up with n additional HTTP requests performed, defeating the whole purpose of embedding. Moreover, those fetches will return you the representation available on self-link, which might be totally different from what you expect, as the spec states:The alternative is to use
getEmbedded
, but there's a scary warning and results might here again not be as expected (since a subsequent fetch without embedded resources would wipe them out). Moreover, even when usinggetEmbedded
, you cannot filter which embedded you'll get back since there's no rel filtering.In its current current approach, it looks very hard to use embedded properly when using ketting. The issues looks related to cache handling but there's no way to disable caching (
NeverCache
is not a switch-off per se).The text was updated successfully, but these errors were encountered: