Cómo probar una API REST con PowerShell e Invoke-RestMethod
Publicado el 2026-10-26 por frfrand
Peticiones GET POST, JSON, autenticación y diagnóstico desde Windows
No hace falta instalar una app nueva para comprobar si tu API REST devuelve los datos correctos. En Windows, PowerShell puede hacer GET, POST y enviar JSON con Invoke-RestMethod. Es especialmente útil cuando el frontend muestra un error pero no sabés si el backend está fallando.
La idea es usarlo para resolver un problema de verdad, no memorizar comandos porque quedan bien en una captura. Vamos con lo esencial, un ejemplo de trabajo y los errores que más conviene evitar.
Qué hace Invoke-RestMethod y cuándo sirve
Invoke-RestMethod interpreta muchas respuestas JSON y permite configurar método, headers y cuerpo. Es distinto de probar sólo el puerto: acá comprobás comportamiento de HTTP, validaciones y autorización.
Si estás aprendiendo, probalo primero en un repositorio o entorno de prueba. Si administrás producción, documentá el estado antes de ejecutar nada que altere archivos, historial o datos. Eso te permite entender qué cambió y recuperarte si te equivocás.
Ejemplo para copiar y entender
$base = 'https://api.ejemplo.com'
Invoke-RestMethod "$base/health" -Method Get
$payload = @{ tour_id = 12; plazas = 2 } | ConvertTo-Json
Invoke-RestMethod "$base/reservas" -Method Post -ContentType 'application/json' -Body $payloadNo copies la orden final sin mirar el estado previo. Los nombres de ramas, host, usuario o rutas son ejemplos; reemplazalos por los de tu proyecto. Algunos comandos modifican archivos o hacen peticiones que pueden escribir datos.
Cómo lo usaría paso a paso
- Paso 1. Empieza por GET en una ruta que no exponga datos privados.
- Paso 2. Usa un ambiente de pruebas y datos ficticios para solicitudes POST.
- Paso 3. Construye el JSON con
ConvertTo-Jsonen vez de concatenar cadenas manualmente. - Paso 4. Verifica tanto el cuerpo como el código de estado, incluido 400, 401, 403 y 500.
- Paso 5. Si la API requiere autenticación, pasa la credencial por un método seguro, nunca en capturas o repositorios.
Detente después de cada paso y comprueba el resultado. Si algo falla, anota el mensaje exacto antes de cambiar de estrategia. Saltar entre cinco soluciones aleatorias suele dificultar encontrar la causa real.
Un caso que podría pasarte trabajando con clientes
En una web de tours, el navegador no logra confirmar una reserva. Ejecutas el mismo POST desde PowerShell; si devuelve 409 por falta de plazas, el backend está protegiendo disponibilidad. Si devuelve 500, investigas logs y transacciones.
El objetivo no es que «funcione una vez», sino que puedas explicar cómo lo repites sin comprometer otra aplicación. Si hay datos o credenciales de clientes, trabaja con pruebas separadas y accesos mínimos.
El error que más veo
Un 200 no prueba que se haya guardado algo; comprueba el registro en el backend. Los comandos POST pueden crear reservas reales: no los lances contra producción con datos de ejemplo sin control.
Una regla sencilla: si no puedes explicar qué hará el comando sobre tu código o servidor, mira primero su ayuda oficial. Así evitarás confundir una solución rápida con un problema nuevo.
¿Dónde entra ArduMaker?
Si la API está en ArduMaker, compara la respuesta HTTP desde PowerShell con los logs del servicio y el estado de PostgreSQL. Así no culpas al frontend cuando el error está en la lógica de reservas.
Por ejemplo, puedes desplegar desde un repositorio Git a un VPS, asociar un dominio HTTPS y administrar servicios y bases desde el mismo entorno. El panel reduce tareas repetitivas de infraestructura, pero no reemplaza Git, las pruebas ni la revisión de permisos del proyecto.
Preguntas rápidas antes de aplicarlo
¿Esto cambia producción? Depende de dónde ejecutes la acción. Prueba localmente primero, identifica el commit o servicio afectado y prepara un plan de recuperación.
¿Cómo compruebo que salió bien? No te quedes con la ausencia de mensajes de error: revisa el estado, ejecuta un test funcional y comprueba los logs o el historial correspondiente.
¿Conviene automatizarlo? Si es repetible y tiene resultados verificables, sí. Pero la automatización debería fallar de forma clara y no esconder errores o credenciales.
Para ampliar
Resumen: la herramienta útil no es la que tiene más opciones, sino la que te permite entender qué cambió, comprobarlo y seguir trabajando sin sorpresas.