Curso de Introducción a los Microservicios

Rest Client como alternativa a Swagger en VS Code

Curso de Introducción a los Microservicios

Contenido del curso

Rest Client como alternativa a Swagger en VS Code

Resumen

Probar APIs desde Visual Studio Code es posible con Rest Client, una extensión que reemplaza a Swagger y Postman para acelerar las consultas HTTP en proyectos con microservicios. Si trabajas con ASP.NET Web API y quieres optimizar tu flujo de pruebas, esta herramienta te ahorra horas de trabajo sin pivotear entre interfaces.

¿Por qué cambiar Swagger por Rest Client en proyectos con microservicios?

Swagger tiene una interfaz visual muy clara para documentar y probar endpoints, pero en ambientes productivos con muchos microservicios se vuelve lento navegar entre tantas pantallas. Cuando necesitas validar varias rutas seguidas, abrir el navegador, expandir cada operación, presionar Try it out y luego Execute termina robando minutos valiosos.

Ahí entra Rest Client, una extensión de Visual Studio Code con casi 6 millones de descargas, lo que la posiciona como una de las más populares del marketplace [0:30]. La idea es simple: ejecutar consultas HTTP directamente desde el editor, sin salir de tu entorno de desarrollo.

¿Qué es Rest Client? Es una extensión de VS Code que permite enviar peticiones HTTP desde un archivo de texto plano y ver la respuesta dentro del propio editor, sin abrir Postman ni Swagger.

¿Cómo funciona el archivo .http en plantillas de ASP.NET Web API?

Cuando generas un proyecto con la plantilla de ASP.NET Web API, el scaffolding incluye automáticamente un archivo con extensión .http. En el ejemplo que estamos siguiendo, el archivo se llama AddMember.http y trae preconfigurada la dirección local junto con el puerto que la plantilla asignó por defecto, en este caso el 5242 [1:30].

Ese archivo es totalmente compatible con Rest Client. Dentro encuentras la URL base, las variables del entorno y un método de ejemplo apuntando a WeatherForecast, que es el endpoint clásico de las plantillas de Microsoft.

La estructura típica incluye:

  • La dirección local con el puerto correspondiente.
  • El verbo HTTP que vas a invocar.
  • La ruta del método, por ejemplo WeatherForecast.
  • Cabeceras opcionales como Content-Type.

¿Cómo enviar una solicitud HTTP desde VS Code?

Una vez que tu aplicación está ejecutándose en el puerto correcto, basta con abrir el archivo .http y hacer clic en la opción Send Request que aparece sobre cada bloque de petición. La respuesta se despliega en una pestaña lateral en milisegundos.

Si recibes un error de conexión cerrada, lo más probable es que el servidor no esté corriendo o que el puerto no coincida con el de tu aplicación. Reinicia el proyecto y verifica que el puerto del archivo .http sea exactamente el mismo que muestra la terminal al levantar la API.

¿Qué pasa si uso el verbo HTTP equivocado?

Un detalle importante: Rest Client respeta estrictamente el verbo que escribas. Si tu endpoint está definido con MapGet en Program.cs pero envías un POST, vas a recibir el clásico mensaje Method Not Allowed [3:00]. Cambia el verbo a GET y la solicitud devuelve el JSON esperado.

¿Por qué aparece el error Method Not Allowed? Porque el verbo HTTP de tu petición no coincide con el que está registrado en el endpoint. Si la ruta está definida como MapGet, debes enviar GET, no POST.

¿Qué ventajas tiene usar Rest Client frente a Postman o Swagger?

La respuesta JSON que obtienes con Rest Client es exactamente la misma que verías en Swagger, solo que integrada en tu editor. Eso significa que copias, pegas y modificas peticiones con la misma agilidad con la que escribes código.

Entre los beneficios prácticos destacan:

  • Versionar tus pruebas junto con el código en Git.
  • Evitar saltar entre Swagger, Postman y el navegador.
  • Reutilizar variables y entornos dentro del mismo archivo.
  • Documentar las llamadas HTTP de forma legible para todo el equipo.

El autocompletado también ayuda: cuando empiezas a escribir cabeceras como Content-Type, la extensión sugiere el valor y solo necesitas presionar tabulador para aceptarlo. Pequeños detalles que suman cuando pruebas decenas de endpoints al día.

¿Cuándo conviene seguir usando Swagger?

Swagger sigue siendo excelente para mostrar la API a personas que no la conocen, porque la documentación visual es muy explicativa. Pero para el día a día de un desarrollador que ya conoce sus rutas y solo quiere validar respuestas rápidas, Rest Client es más directo.

La idea no es eliminar Swagger del proyecto, sino tener una herramienta complementaria que te permita iterar más rápido durante el desarrollo y dejar la interfaz visual para demos, onboarding o consumidores externos de la API.

¿Ya probaste Rest Client en tus proyectos de microservicios? Cuéntame en los comentarios cómo te fue y qué flujo de pruebas usas tú.