Сброс данных

Каждая запись в ресурс — каждый POST, PUT, PATCH и DELETE — сохраняется как небольшое переопределение поверх сгенерированных данных, а не как изменение самой генерации. Это значит, что отмена всех этих изменений — единая, полная, мгновенная операция: сбросьте ресурс, и каждое переопределение будет удалено. Следующее чтение регенерирует те же данные, что вы получили бы от совершенно нового ресурса с той же схемой, сидом и count — байт в байт, потому что логика генерации ни разу никуда не сдвинулась.

Почему это безопасно

Сравните это с инструментом для фейковых API на базе настоящей базы данных вставленных строк: там «сброс» обычно означает повторный запуск скрипта заполнения, и нет никакой гарантии, что он воспроизведёт в точности то же самое, что было раньше, если скрипт или его источник случайности хоть немного изменился. У сброса в MockLab такого риска нет, потому что сгенерированная базовая версия изначально не затрагивалась — ваши записи целиком жили в отдельном слое переопределений. Удаление этого слоя и есть сброс, и регенерировать заново нечего и негде ошибиться.

Откуда сбрасывать

Сброс — это действие владельца проекта, а не то, что вызывает публичный потребитель API: оно доступно через вашу сессию в дашборде, а не через эндпоинт /m/..., который вызывает ваше приложение. На странице ресурса в дашборде используйте действие сброса, чтобы очистить все переопределения для этого ресурса. Здесь нет шага подтверждения, который можно было бы автоматизировать скриптом, и нет частичного сброса: это всё или ничего, намеренно, поскольку выборочный сброс потребовал бы отличать «это осознанная правка, которую я хочу сохранить» от «это были тестовые данные» — а такое различие API знать не может.

Что происходит на самом деле

Под капотом сброс удаляет каждую строку переопределения, принадлежащую ресурсу, и увеличивает его внутреннюю версию данных — тот самый номер версии, который служит ключом кеша в памяти, из которого обслуживаются ваши чтения. Именно это единственное увеличение делает недействительной каждую закешированную страницу для этого ресурса на каждом серверном процессе; самый первый следующий GET, откуда бы он ни пришёл, регенерирует данные и кеширует их заново с чистого листа.

Когда это пригодится

Сброс полезнее всего в процессе разработки: вы поигрались с ресурсом через интерфейс своего приложения — создали тестовые записи, удалили несколько, поправили цены, чтобы проверить граничный случай, — и хотите снова получить чистую базовую версию перед демонстрацией, тестированием или передачей эндпоинта кому-то ещё. Поскольку генерация детерминирована, каждый, кто обращается к сброшенному ресурсу после этого, видит абсолютно одинаковые данные, а значит проще писать тесты или документацию с опорой на фиксированные ожидаемые значения.

Чтение данных после сброса

Чтение ресурса после сброса использует тот же самый эндпоинт, что и всегда — ничего в URL или форме ответа не меняется:

const response = await fetch("https://mocklab.dev/m/demo7k2m9x/products");
const products = await response.json();
// Identical to a fresh resource with the same schema, seed and count.

import { useQuery, useQueryClient } from "@tanstack/react-query";

function ProductList() {
  const queryClient = useQueryClient();
  const { data: products } = useQuery({
    queryKey: ["products"],
    queryFn: () => fetch("https://mocklab.dev/m/demo7k2m9x/products").then((res) => res.json()),
  });

  // After resetting from the dashboard, invalidate the cached query so the
  // next render reflects the clean baseline instead of stale overridden data.
  const refetchAfterReset = () => queryClient.invalidateQueries({ queryKey: ["products"] });

  return (
    <>
      <button onClick={refetchAfterReset}>Refresh</button>
      <ul>
        {products?.map((p) => (
          <li key={p.id}>{p.title}</li>
        ))}
      </ul>
    </>
  );
}