Cache Control and ETag headers
Turning on an endpoint's existing Cache setting (in its Settings panel) does two things now: it still drives the server side response cache it always did, and it also sets real Cache-Control and ETag headers on a successful GET response, so the calling browser, app, or CDN can skip asking again entirely until the cache's TTL passes. The header reads public when the endpoint is open to anyone, or private when it requires an API key, since a keyed response is specific to whoever called it and must never be served to a different caller from a shared cache.
If the caller sends back the ETag they were given (as an If-None-Match header) and it still matches, they get a fast, empty bodied 304 Not Modified instead of the full response again. An endpoint with caching off sends an explicit Cache-Control: no-store, so a caller never has to guess whether it's safe to cache.
Requesting fewer fields
A select type Database Query block already returns every field on each matching record. A caller can now trim that down by adding ?fields= to their request, a comma separated list of field names, e.g. GET /items?fields=id,name. Only those keys (plus id, which always comes back regardless) appear in each returned record. Leave it off and nothing changes, every field comes back exactly as before, this is entirely opt in from the caller's side, nothing to configure on the block itself.
Tip: Sparse fieldsets pair well with a large collection: a caller listing just enough to build a dropdown (id and name) gets a smaller, faster response than fetching every field on every row.