Preciso de uma conta para criar um endpoint mock de API REST?

Não. Não há cadastro, nem e-mail, nem chave de API — você faz o POST da definição do mock e recebe uma URL ativa de volta. Cada mock retorna um token de administrador de uso único que você guarda caso queira editá-lo ou excluí-lo depois.

Por quanto tempo o endpoint fica ativo?

Sete dias por padrão, trinta no máximo. Isso cobre o intervalo habitual entre "o frontend está pronto" e "o backend está pronto", e a expiração impede que simulações desatualizadas vazem para a produção.

A resposta pode mudar entre as chamadas?

Sim. Use tokens faker para um corpo novo a cada chamada, uma sequência de respostas para retornar status diferentes em ordem, ou um atraso para simular um endpoint lento. Um corpo fixo é apenas o caso mais simples.

Simular um endpoint de API REST

Obtenha um endpoint JSON público para desbloquear seu frontend antes do backend existir.

Um endpoint de API REST mock é uma URL pública que retorna o JSON que você definiu, sem nenhum servidor próprio por trás. Você descreve o método, o código de status e o corpo da resposta uma vez, e o mock responde a todas as chamadas exatamente com isso. É a maneira mais rápida de desbloquear o trabalho no frontend enquanto o backend real ainda está sendo escrito: criar um mock e chamá-lo levou uma média de 0,73 segundos em 20 execuções de um cliente europeu, medido em 2026-09-08.

Qual JSON o mock deve retornar?

Retorne a resposta que sua interface realmente espera, não um substituto simplificado. Todo o valor do mock é que você escreve código real de análise contra ele, então o formato deve corresponder ao contrato que você concordou com a equipe de backend.

Mantenha o envelope. Se a API real envolve os resultados como {"data": [...], "total": 42}, simule o envelope também. Código escrito contra um array simples quebra no dia em que o endpoint real chega.
Mantenha os tipos. Um id que é uma string em produção deve ser uma string aqui. O desvio silencioso de número para string é a causa mais comum de um mock que funciona e uma chamada real que não.
Inclua os campos difíceis. Nulos, arrays vazios e chaves opcionais são exatamente o que seu código de renderização erra, então coloque pelo menos um de cada na amostra.

Como você simula respostas de erro e CORS?

Um mock que retorna apenas 200 testa metade do seu código. Defina response_status como 404, 422 ou 500 e aponte um segundo mock para ele, de modo que seus caminhos de erro sejam exercitados de forma tão deliberada quanto o caminho feliz. A referência de códigos de status MDN é a maneira mais rápida de escolher o erro correto.

Se você estiver chamando o mock do navegador em vez do curl, defina cors_enabled como true. Sem isso, o navegador bloqueia a resposta antes que seu código a veja, e o erro do console raramente cita a causa real — veja MDN sobre CORS. Para corpos de erro que valem a pena padronizar, a RFC 9457 Problem Details oferece um formato que o resto do setor já analisa.

Como você troca o mock pela API real depois?

Coloque a URL base na configuração no primeiro dia, nunca embutida (inline) num componente. Aponte para a URL do mock agora e para o host real depois, e a troca será uma mudança de uma linha em vez de uma busca por toda a base de código.

Mocks aqui duram sete dias por padrão e até trinta no máximo, o que geralmente é maior do que o intervalo que você está cobrindo. Essa expiração é uma funcionalidade: um mock que sobrevive silenciosamente ao endpoint real é como um dado falso acaba em produção. Se um colega de equipe precisar do mesmo dado, compartilhe o comando de criação em vez da URL, para que todos possam gerá-lo de novo.

O que geralmente dá errado?

Simular a resposta que você gostaria de ter. Projete o mock com base no contrato real do backend, não no que seria conveniente renderizar.
Esquecer o tipo de conteúdo. Sem "content_type": "application/json" muitos clientes te entregam uma string e seu analisador falha em JSON válido.
Testar apenas o caminho feliz. Se nenhum teste chega a ver um 500, seu tratamento de erros não está comprovado, muito menos correto.
Deixar a URL do mock em uma branch mesclada. Configuração, não código-fonte, e a expiração de sete dias impede que se torne permanente.

Quando usar isso

Quando o backend não está pronto, o frontend para. Monte um mock que retorne o JSON exato que sua interface espera, obtenha uma URL pública e construa com base nisso agora — troque pela API real mais tarde.

Criar o mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"users\":[{\"id\":1,\"name\":\"Ada\"}]}"
}'

Chamá-lo

curl https://quickmock.dev/m/<slug>

O que você obtém

{"users":[{"id":1,"name":"Ada"}]}

FAQ

Preciso de uma conta para criar um endpoint mock de API REST?: Não. Não há cadastro, nem e-mail, nem chave de API — você faz o POST da definição do mock e recebe uma URL ativa de volta. Cada mock retorna um token de administrador de uso único que você guarda caso queira editá-lo ou excluí-lo depois.
Por quanto tempo o endpoint fica ativo?: Sete dias por padrão, trinta no máximo. Isso cobre o intervalo habitual entre "o frontend está pronto" e "o backend está pronto", e a expiração impede que simulações desatualizadas vazem para a produção.
A resposta pode mudar entre as chamadas?: Sim. Use tokens faker para um corpo novo a cada chamada, uma sequência de respostas para retornar status diferentes em ordem, ou um atraso para simular um endpoint lento. Um corpo fixo é apenas o caso mais simples.

Construa o seu próprio

Criar um mock

Templates prontos para isso: Simular uma resposta de token OAuth2, Simular um documento de descoberta OpenID Connect, Simular um endpoint JWKS para verificação de JWT

Guias relacionados

← Todos os guias

Última atualização: 2026-10-17