Создание, обновление и удаление

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

Создание записи

Отправьте POST на коллекционный эндпоинт с телом в виде JSON-объекта. Сервер всегда сам назначает id — если ваше тело содержит его, он будет отброшен в пользу настоящего — и возвращает созданную запись со статусом 201.

curl -X POST https://mocklab.dev/m/demo7k2m9x/products \
  -H "Content-Type: application/json" \
  -d '{"title": "Desk lamp", "price": "$34.00", "inStock": true}'

const response = await fetch("https://mocklab.dev/m/demo7k2m9x/products", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ title: "Desk lamp", price: "$34.00", inStock: true }),
});
const created = await response.json(); // { id: "...", title: "Desk lamp", ... }

Замена записи через PUT

PUT на /m/{project-key}/{resource-name}/{id} полностью заменяет запись вашим телом — любое поле, которое вы не отправили, исчезает из результата, в точности как в семантике PUT настоящего REST API. Возвращает 200 с полной заменённой записью.

await fetch(`https://mocklab.dev/m/demo7k2m9x/products/${id}`, {
  method: "PUT",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ title: "Desk lamp", price: "$29.00", inStock: false }),
});

Обновление записи через PATCH

PATCH объединяет ваше тело с текущим значением записи — сгенерированным или уже переопределённым, — так что меняются только отправленные ключи. Это почти всегда то, что нужно для формы «редактировать одно поле».

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

function useUpdatePrice(productId) {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (price) =>
      fetch(`https://mocklab.dev/m/demo7k2m9x/products/${productId}`, {
        method: "PATCH",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ price }),
      }).then((res) => res.json()),
    onSuccess: () => queryClient.invalidateQueries({ queryKey: ["products"] }),
  });
}

Удаление записи

Отправьте DELETE на тот же URL одной записи. Возвращает 204 без тела — запись больше не появляется ни в результатах списка, ни при прямом GET по id.

await fetch(`https://mocklab.dev/m/demo7k2m9x/products/${id}`, { method: "DELETE" });

Что не проверяется

Ни один из этих эндпоинтов записи не проверяет тело на соответствие типам полей ресурса — весь смысл фейкового API в том, чтобы принимать любую форму данных, которую отправляет клиент в процессе активной разработки, не заставляя вас держать схему в идеальной синхронизации. Единственное требование — чтобы тело было JSON-объектом для POST/PUT/PATCH. Отправьте поле, которого нет в схеме, — и оно будет сохранено и возвращено точно так, как отправлено; не отправьте значение для поля, которое схема определяет, — и при PUT его просто не будет в результате.

Одна оговорка для ресурсов свыше 10 000 записей

GET/PUT/PATCH/DELETE для одной записи по id работают только для записей, у которых уже есть переопределение — либо созданных через POST, либо обычных сгенерированных записей, к которым вы уже обращались хотя бы раз для записи. На ресурсе с более чем 10 000 записей id, принадлежащий обычной, ни разу не тронутой сгенерированной записи, вернёт 404 на этих маршрутах, потому что определить, какому индексу принадлежит произвольный id, означало бы генерировать записи до тех пор, пока не найдётся совпадение — именно тот полный перебор, ради предотвращения которого и существует порог в 10 000. Полное объяснение — в разделе Как устроена генерация.