O cliente de APIs
que é seu.
Arquivos .http no seu próprio repositório. MIT para sempre. Sem conta, sem cloud, sem lock-in: suas requisições continuam sendo texto puro que você lê em qualquer editor, mesmo se o Fetchpier desaparecer amanhã.
# @post-response-script# fp.test('user found', () => fp.expect(fp.response.status).to.equal(200))# @end-script GET {{baseUrl}}/users/42Authorization: Bearer {{token}}Essa é a requisição inteira, com o teste incluído. Um arquivo de texto no seu repo: dá para ver o diff, revisar, e é seu.
Vindo do VS Code REST Client ou do JetBrains HTTP Client? Leia as notas de compatibilidade →
Compare por defaults,
não por features.
Todo cliente de APIs escolhe seus padrões. O Fetchpier escolhe estes de propósito: suas requisições vivem no seu repo, todos os recursos são gratuitos e o app não envia nada que você não pediu.
- Conta e sincronização na nuvem por padrão — suas coleções vivem no servidor de outra pessoa
- Recursos avançados num plano pago — até em clientes open source
- Telemetria ou tráfego em segundo plano que você não vê
- CAs corporativas e proxies que falham de formas misteriosas
- Sem conta. Seu workspace é uma pasta de arquivos .http simples no seu próprio repo
- MIT, todos os recursos. Nunca haverá um plano pago do cliente
- Sem telemetria. Uma única conexão própria: uma verificação de versão que você dispara. A interface não pode abrir conexões, e lint, uma auditoria do bundle e um teste end-to-end verificam isso.
- Um conjunto de CAs explícito e TLS com escopo de workspace ou de app — proxies MITM corporativos se comportam de forma previsível
Suas coleções são pastas. Suas requests são arquivos.
Sem bancos de dados escondidos. Sem formatos proprietários. Seu workspace é só uma pasta no disco — abra com qualquer editor, compartilhe via Git, mova entre máquinas sem mágica. Requisições simples também rodam no VS Code REST Client e no JetBrains HTTP Client, depois que você define as variáveis lá.
Code review para suas APIs.
Pull requests, diffs, branches. Seu time revisa mudanças de API do mesmo jeito que revisa código — porque são código. Sem plataformas proprietárias, sem assentos para pagar.
Um editor feito por developers.
Variáveis com sintaxe {{ }} e autocompletar. Params, headers e bodies: JSON, form-data, urlencoded, raw e binário. Auth: Bearer, Basic e API key — OAuth2 é o próximo item do roadmap. Sem CORS: as requisições saem do app, não de um navegador.
Scripts pré e pós request, em um sandbox restrito.
Gere dados, autentique requisições, modifique headers antes de enviar e faça asserções sobre a resposta com fp.expect. Os scripts são JavaScript simples guardado no arquivo .http, rodam de forma síncrona sobre uma API fp pequena, e o sandbox é coberto por testes de regressão. Ele protege contra acidentes, não contra código hostil: revise os scripts de workspaces em que você não confia.
O essencial do dia a dia.
Com padrões que mantêm seu trabalho na sua máquina.
Environments & Variables
Separe dev, staging e prod com environments. Cookie jar RFC 6265 por environment. Segredos criptografados no próprio arquivo, seguros para commitar e compartilhar via Git — ou fora do repo em um arquivo .env.
Histórico integrado
Cada envio fica guardado como um registro .http simples no seu workspace — requisição, resposta, scripts e cookies —, ignorado pelo Git por padrão e nunca enviado a lugar nenhum.
Command palette
Ctrl/Cmd+P para saltar entre arquivos, rodar requests ou invocar ações sem mouse.
Importadores nativos
OpenAPI 2/3, Swagger, GraphQL SDL e introspection, WSDL/SOAP, coleções Postman v2.0/v2.1. Convertidos em arquivos .http editáveis.
Dark / Light mode
Dark por default. Light igualmente polido. Sem flashes estranhos ao carregar.
O Authorization fica onde está
Os headers Authorization são removidos por padrão em redirecionamentos para outro host, então um redirect não leva seu token para outro servidor.
Seu API workflow, no seu repo.
O mesmo repo onde seu backend vive guarda as requests que o testam. Um commit, uma PR, um workflow.
As mesmas requisições, agora no seu pipeline.
O fp roda as requisições do seu workspace a partir de um terminal ou de um job de CI com o mesmo motor do app desktop: as mesmas variáveis, auth, cookies, scripts e testes.
npm install -g @fetchpier/clifp init my-apicd my-apifp runfp run --reporter-junit out.xmlUm motor, duas superfícies
Uma requisição se comporta igual no app e no fp run. O que um script grava chega à próxima requisição da execução: o token de um login chega à chamada autenticada.
Relatórios que seu CI entende
Relatórios JSON, JUnit e HTML independente na mesma execução, e um código de saída diferente para cada resultado, para o pipeline distinguir um teste que falhou de um ambiente inexistente.
Segredos continuam secretos
Variáveis criptografadas são resolvidas com FETCHPIER_WORKSPACE_KEY a partir do cofre de segredos do seu CI. Relatórios e terminal mascaram segredos, credenciais e cookies.
Feito para redes reais
Respeita HTTPS_PROXY e NO_PROXY, aplica por padrão um timeout de 30 segundos por requisição e usa os certificados TLS versionados com o workspace.
Transparência por design.
Tudo que roda na sua máquina é grátis para sempre. Leia o código, abra um issue, proponha um feature ou faça um fork. Sem roadmap escondido.
Ver o código
Explore o código, os testes e as verificações que o protegem, e as issues abertas.
Reportar um bug
Se algo não funciona como esperado, abra um issue. Lemos todos.
Como ajudar
Relatos de bugs e ideias de recursos são bem-vindos. Pull requests externos ainda não são aceitos — o CONTRIBUTING explica por quê e o que fazer em vez disso.