O problema dos mocks "burros"
Mock rules tradicionais retornam sempre a mesma resposta: GET /users sempre retorna os mesmos 3 usuários. POST /users cria o registro na memória... até o servidor reiniciar. Isso é suficiente para testar uma tela estática, mas falha quando você precisa testar fluxos completos.
E se o mock agisse como um banco de dados real — criando, buscando, atualizando e deletando registros com persistência entre requisições?
POST /produtos
{nome: "Tênis", preço: 299}
{nome: "Tênis", preço: 299}
→
httpdrop CRUD
SQLite persistente
SQLite persistente
→
201 Created
{id: 1, nome: "Tênis"}
{id: 1, nome: "Tênis"}
O que o CRUD automático gera
Ao criar uma tabela CRUD para o path /produtos, o httpdrop disponibiliza automaticamente:
MétodoRotaO que faz
GET/produtosLista com paginação e filtros
POST/produtosCria registro, retorna 201
GET/produtos/:idBusca por ID
PUT/produtos/:idSubstitui registro completo
PATCH/produtos/:idAtualiza campos parcialmente
DELETE/produtos/:idRemove registro
Filtros e paginação prontos
Exemplos de query string
GET /produtos?_page=2&_limit=10 GET /produtos?categoria=eletronicos GET /produtos?preco_gte=100&preco_lte=500 GET /produtos?_sort=nome&_order=asc
Casos de uso reais
App mobile — Desenvolva o app completo enquanto o back-end ainda não existe. Teste fluxos de criação, edição e deleção com dados reais persistidos.
Protótipo e demonstração — Mostre uma demo completa e funcional para stakeholders sem precisar de servidor, banco ou deploy.
Testes de integração — Isole o serviço que está testando usando uma API mock com estado real. Sem fixtures, sem seed scripts complicados.
Ensino e bootcamp — Alunos aprendem a consumir APIs REST com dados reais sem precisar configurar back-end, banco de dados ou autenticação.
Seed automático: Use o Faker BR para popular a tabela com dados sintéticos realistas (CPF, nome, email, endereço) em um clique — perfeito para demonstrações e testes.