Можно ли сделать со стороны Frontend чтобы не кэшировались данные из GET запроса?

Да, можно. Хотя кэширование HTTP-запросов по умолчанию регулируется сервером (заголовками Cache-Control, Expires и т.д.), frontend разработчик имеет несколько способов повлиять на это поведение и предотвратить нежелательное кэширование GET-запросов.

Основные стратегии предотвращения кэширования

1. Динамические параметры в URL (Cache-Busting)

Самый распространенный и надежный метод — добавление к URL уникального параметра, который меняется при каждом запросе. Это заставляет браузер и промежуточные кэши воспринимать каждый запрос как уникальный.

// Добавление временной метки (timestamp)
const url = '/api/data?_=' + Date.now();

// Или использование случайного числа
const url = '/api/data?r=' + Math.random();

// Более изящный вариант с performance API
const url = `/api/data?cb=${performance.now()}`;

2. Настройка заголовков запроса через Fetch API или XHR

Можно явно указать желаемую политику кэширования в конфигурации запроса.

// Использование Fetch API с заголовком Cache-Control
fetch('/api/data', {
  method: 'GET',
  headers: {
    'Cache-Control': 'no-cache, no-store, must-revalidate',
    'Pragma': 'no-cache',
    'Expires': '0'
  }
});

// Или использование встроенной опции cache
fetch('/api/data', {
  cache: 'no-store' // Варианты: 'default', 'no-store', 'reload', 'no-cache', 'force-cache', 'only-if-cached'
});

// Для XMLHttpRequest
const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data', true);
xhr.setRequestHeader('Cache-Control', 'no-cache');
xhr.send();

3. Использование POST вместо GET (не рекомендуется)

Хотя технически это работает, это противоречит семантике HTTP (GET предназначен для получения данных, POST — для создания). Этот подход считается антипаттерном и может вызвать проблемы с совместимостью, SEO, логированием и безопасностью.

// Антипаттерн! Не делайте так без крайней необходимости
fetch('/api/data', {
  method: 'POST', // Использование POST для обхода кэширования GET
  headers: {
    'Content-Type': 'application/json'
  }
});

4. Работа с Service Workers

В продвинутых приложениях можно использовать Service Workers для полного контроля над сетевыми запросами.

// В Service Worker можно перехватывать и модифицировать запросы
self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  
  // Добавляем параметр cache-busting для специфических запросов
  if (url.pathname.startsWith('/api/')) {
    url.searchParams.append('_', Date.now());
    const newRequest = new Request(url, event.request);
    event.respondWith(fetch(newRequest));
  }
});

5. Использование библиотек HTTP-клиентов

Современные HTTP-клиенты, такие как axios, предоставляют встроенные механизмы для управления кэшированием.

import axios from 'axios';

// Добавление параметра с временной меткой
axios.get('/api/data', {
  params: {
    timestamp: new Date().getTime()
  }
});

// Или настройка заголовков
axios.get('/api/data', {
  headers: {
    'Cache-Control': 'no-cache'
  }
});

Детальный разбор параметров кэширования Fetch API

Fetch API предоставляет несколько значений для опции cache:

Практические рекомендации

Когда что использовать:

• Динамические параметры — для простых случаев, когда нужно гарантировать свежесть данных
• Заголовки no-cache — когда нужно перепроверять данные на сервере (возвращается 304 Not Modified, если данные не изменились)
• Заголовки no-store — для конфиденциальных или часто меняющихся данных, когда кэширование недопустимо
• Service Workers — для комплексного управления кэшированием в PWA

Важные нюансы:

1. Методы cache-busting не отключают кэширование полностью — они лишь делают каждый запрос уникальным
2. Заголовки запроса могут быть проигнорированы — сервер имеет приоритет в определении политики кэширования через заголовки ответа
3. HTTPS-трафик кэшируется иначе — некоторые промежуточные прокси не кэшируют HTTPS по умолчанию
4. Разные браузеры могут вести себя по-разному — всегда тестируйте на целевых браузерах

Пример комплексного решения

class ApiService {
  constructor(baseUrl) {
    this.baseUrl = baseUrl;
    this.cacheBustingEnabled = true;
  }

  async get(endpoint, useCache = false) {
    let url = `${this.baseUrl}${endpoint}`;
    
    if (this.cacheBustingEnabled && !useCache) {
      const separator = endpoint.includes('?') ? '&' : '?';
      url += `${separator}_=${Date.now()}`;
    }

    const options = {
      method: 'GET',
      cache: useCache ? 'default' : 'no-store',
      headers: {
        'Cache-Control': 'no-cache'
      }
    };

    const response = await fetch(url, options);
    return response.json();
  }
}

// Использование
const api = new ApiService('https://api.example.com');
const freshData = await api.get('/data'); // Без кэширования
const cachedData = await api.get('/static-data', true); // С кэшированием

Заключение

Да, frontend разработчик может и должен управлять кэшированием GET-запросов, но важно понимать, что это коллаборативный процесс между клиентом и сервером. Наиболее эффективный подход — комбинация методов: использование cache-busting параметров для критически важных динамических данных и правильная настройка заголовков запросов. При этом всегда следует учитывать, что серверные заголовки ответа (Cache-Control, ETag, Last-Modified) имеют более высокий приоритет в финальном определении политики кэширования.