Cache Control und ETag Header
Die bestehende Cache Einstellung eines Endpunkts (im Settings Panel) einzuschalten macht jetzt zwei Dinge: sie steuert weiterhin den serverseitigen Antwort Cache, wie sie es immer tat, und sie setzt auch echte Cache-Control und ETag Header auf eine erfolgreiche GET Antwort, sodass der aufrufende Browser, die App, oder der CDN eine erneute Anfrage komplett überspringen kann, bis die TTL des Caches abläuft. Der Header liest public, wenn der Endpunkt für jeden offen ist, oder private, wenn er einen API Schlüssel verlangt, da eine schlüsselgebundene Antwort spezifisch für den Aufrufer ist und nie aus einem geteilten Cache an einen anderen Aufrufer ausgeliefert werden darf.
Wenn der Aufrufer den ihm gegebenen ETag zurücksendet (als If-None-Match Header) und er noch übereinstimmt, bekommt er ein schnelles, body loses 304 Not Modified statt der vollständigen Antwort erneut. Ein Endpunkt mit ausgeschaltetem Caching sendet ein explizites Cache-Control: no-store, sodass ein Aufrufer nie raten muss, ob es sicher ist zu cachen.
Weniger Felder anfragen
Ein select artiger Database Query Block gibt bereits jedes Feld jedes passenden Records zurück. Ein Aufrufer kann das jetzt eingrenzen, indem er ?fields= zu seiner Anfrage hinzufügt, eine kommagetrennte Liste von Feldnamen, z. B. GET /items?fields=id,name. Nur diese Schlüssel (plus id, die immer unabhängig davon zurückkommt) erscheinen in jedem zurückgegebenen Record. Lass es weg, und nichts ändert sich, jedes Feld kommt genau wie zuvor zurück, das ist komplett opt in auf Seiten des Aufrufers, nichts am Block selbst zu konfigurieren.
Tipp: Sparse Fieldsets passen gut zu einer großen Collection: ein Aufrufer, der nur genug für ein Dropdown auflistet (id und name), bekommt eine kleinere, schnellere Antwort, als jedes Feld auf jeder Zeile abzurufen.