HTTP API should leverage HTTP Cache (via Etag or Last-Modified-Since headers)

[azasypkin]

Ideally every "get-like/read" response should include proper http cache headers. It will help client app to consume less traffic (at least in its current state when polling is heavily used) and reduce server load (maybe we don't expect too many requests though).

The only thing I'm not sure of is if it's possible to do a proper caching of POST responses at all :/

cc @Yoric @fabricedesre

[Yoric]

This would definitely make sense for the lists of services and channels.

Not so much for interaction with adapters, of course.

[azasypkin]

Not so much for interaction with adapters, of course.

Mmm, what is reason that prevents us from leveraging HTTP Cache for channels/get as well?

[Yoric]

I guess we could ask Adapters to provide an Etag if they want to support caching fetch operations.

[azasypkin]

Yep, that would probably work, but will basically tie adapters to HTTP and introduce more complexity inside adapter :/

Can't REST layer somehow determine (before or after serialization) that response it's going to return hasn't changed? It will also cover http requests that consist of multiple "adapter fetch requests" that we use currently (and it's pretty awesome feature btw!).