Caché del lado del cliente (Cache Control, ETag) y solicitar menos campos

Encabezados Cache Control y ETag

Activar el ajuste Cache existente de un endpoint (en su panel Settings) ahora hace dos cosas: sigue impulsando la caché de respuesta del lado del servidor que siempre impulsó, y además establece encabezados reales Cache-Control y ETag en una respuesta GET exitosa, de modo que el navegador, aplicación, o CDN que llama puede saltarse por completo volver a preguntar hasta que pase el TTL de la caché. El encabezado dice public cuando el endpoint está abierto para cualquiera, o private cuando requiere una clave de API, ya que una respuesta con clave es específica de quien la llamó y nunca debe servirse a un llamante diferente desde una caché compartida.

Si quien llama devuelve el ETag que recibió (como un encabezado If-None-Match) y todavía coincide, obtiene un rápido 304 Not Modified con el cuerpo vacío en lugar de la respuesta completa de nuevo. Un endpoint con la caché desactivada envía un Cache-Control: no-store explícito, así quien llama nunca tiene que adivinar si es seguro cachear.

Solicitar menos campos

Un bloque Database Query de tipo select ya devuelve todos los campos de cada registro coincidente. Ahora quien llama puede reducir eso añadiendo ?fields= a su solicitud, una lista de nombres de campos separados por comas, por ejemplo GET /items?fields=id,name. Solo esas claves (más id, que siempre vuelve de todas formas) aparecen en cada registro devuelto. Si se omite, no cambia nada, todos los campos vuelven exactamente como antes, esto es completamente opcional desde el lado de quien llama, no hay nada que configurar en el propio bloque.