Probar una API en .NET nunca había sido tan directo como ahora. Con la llegada del archivo .http en .NET 10, Postman y el Endpoints Explorer de Visual Studio, tienes tres caminos claros para validar que tus endpoints respondan como esperas, sin salir del editor o desde una interfaz gráfica completa.

¿Qué es el archivo .http en .NET 10 y cómo funciona?

El archivo .http es la novedad que trae el template de .NET 10 para que pruebes tu API directamente desde el proyecto. Lo interesante es que este archivo viaja junto con tu código en Git, así que funciona casi como documentación viva del proyecto [0:14].

Su sintaxis es muy simple. Defines variables con un @ al inicio, escribes la URL base y luego el verbo HTTP con el endpoint específico:

http @HostAddress = http://localhost:5000

GET {{HostAddress}}/weatherforecast

¿Por qué separar la URL base del endpoint? Porque la URL base cambia constantemente: desarrollo, testing, QA, producción, distintos puertos. Lo que nunca cambia es la ruta del endpoint. Con esa estructura, pruebas todos los ambientes solo modificando una variable.

¿Qué hace el archivo .http en un proyecto .NET? Permite ejecutar peticiones HTTP (GET, POST, PUT, DELETE) desde el editor, guardar esas pruebas en el repositorio y compartirlas con tu equipo como parte del proyecto.

¿Qué necesitas instalar para que funcione el archivo .http?

Un detalle clave: al momento de grabar este curso, necesitas tener instalado el SDK de .NET 9 para que la herramienta funcione, aunque tu proyecto use .NET 10 [1:05]. Para verificar que todo esté en orden, abre la ventana Interactive console en Visual Studio. Si ahí aparece un error, lo más probable es que la ejecución no funcione.

Cuando le das clic a Send Request, se abre una ventana con los detalles de la ejecución: tiempo de respuesta, tamaño, headers enviados y recibidos, y el body. Si la API no está corriendo, verás un error; al levantar el proyecto, el archivo reintenta la petición automáticamente y te devuelve el JSON esperado.

¿Cómo generar peticiones automáticas con Endpoints Explorer?

Visual Studio incluye una utilidad muy práctica que muchos pasan por alto. La encuentras en View → Other Windows → Endpoints Explorer [3:10]. Esta ventana lista todos los endpoints que tu API expone.

En un proyecto recién creado solo verás WeatherForecast, pero la magia aparece cuando haces clic derecho sobre cualquier endpoint y eliges Generate Request. Visual Studio escribe por ti la petición correspondiente en el archivo .http.

• Elimina el trabajo manual de escribir cada petición.
• Mantiene sincronizado tu archivo de pruebas con los endpoints reales.
• Acelera el flujo cuando tu API crece a decenas de rutas.

Mientras más endpoints tengas, más rentable se vuelve esta herramienta.

¿Cuándo conviene usar Postman en lugar del archivo .http?

Postman sigue siendo el estándar de la industria para pruebas de APIs, y por buenas razones. Su interfaz gráfica te deja elegir el verbo (GET, POST, PUT, PATCH, DELETE), pegar la URL y darle Send para ver la respuesta, el body y los detalles de la petición [4:18].

Lo que hace a Postman especialmente potente son tres áreas:

• Authorization: soporta prácticamente todos los esquemas de autenticación existentes.
• Headers personalizados: útiles cuando tu API exige tokens, API keys o metadatos específicos.
• Body estructurado: indispensable para POST y PATCH, donde envías el JSON con los datos del recurso a crear o actualizar.

¿Cuál es la diferencia entre el archivo .http y Postman? El archivo .http vive dentro del proyecto y se versiona en Git; Postman es una app externa con interfaz gráfica, autenticación avanzada y collections compartibles entre equipos.

¿Qué son las colecciones de Postman y por qué usarlas?

Las collections te permiten agrupar todas las peticiones de un proyecto en un solo lugar, organizadas por carpetas. El reto que te dejo: explora las utilidades de Postman y crea una colección para este curso de APIs con .NET donde guardes cada petición que aprendas a construir.

¿Por qué falla una API al llamarla desde un archivo HTML?

Aquí viene una situación que vas a encontrar tarde o temprano. En los recursos de la clase hay un archivo HTML de prueba; descárgalo y revisa el script, donde está la ruta a tu API [6:30]. Esa ruta cambia según tu localhost y puerto, así que actualízala antes de probar.

Al ejecutar el HTML con la API corriendo, los datos siguen sin aparecer. ¿Qué sucede? Abre la consola del navegador y verás este mensaje:

From origin 'null' has been blocked by CORS policy

Esto se debe a CORS (Cross Origin Resource Sharing), una configuración de seguridad que las APIs deben definir explícitamente para permitir que clientes en otros dominios las consuman. Sin esa configuración, el navegador bloquea la petición por defecto.

¿Te ha pasado algo parecido al consumir tu propia API desde el frontend? Cuéntame en los comentarios cómo lo resolviste o qué herramienta de prueba prefieres usar en tu día a día.