Probar una API en .NET 10 ya no requiere depender únicamente de herramientas externas. La plantilla base incluye un archivo .http que permite ejecutar peticiones desde el mismo proyecto, y junto con Postman y un cliente HTML, tienes un set completo para validar tus endpoints en cualquier ambiente.
¿Qué es el archivo .http en .NET 10 y para qué sirve?
Cuando creas un proyecto con la plantilla de Web API en .NET 10, aparece un archivo con extensión .http que viaja con el repositorio en Git. Eso significa que tus pruebas quedan versionadas junto al código, casi como documentación viva del proyecto.
La estructura es simple. Defines variables con @, como una host_address que apunta a la URL base de tu API, y luego escribes peticiones con cualquier verbo HTTP apuntando al endpoint específico de tu controlador, por ejemplo WeatherForecast.
¿Por qué separar la URL base del endpoint? Porque la base cambia entre ambientes (desarrollo, QA, producción) e incluso entre puertos locales, pero la ruta del endpoint permanece estable. Cambias una variable y reutilizas todas las peticiones.
¿Cómo ejecutar una petición desde el archivo .http?
Abres el archivo, presionas Send Request sobre la petición y se despliega una ventana con el detalle de la ejecución. Si la API no está corriendo, verás un error claro indicando que no hay respuesta.
Un detalle importante al momento de grabar este flujo: aunque trabajes en .NET 10, la herramienta requiere tener instalado el SDK de .NET 9 porque aún no se ha actualizado a la versión 10. Si algo falla, revisa la consola Interactive dentro de Visual Studio, ahí aparecen los errores reales de la herramienta.
Una vez que ejecutas el proyecto, el archivo .http reintenta la petición automáticamente y devuelve el JSON de prueba con datos útiles: tiempo de respuesta, tamaño, encabezados enviados y recibidos, y el cuerpo de la respuesta.
¿Cómo generar peticiones automáticas con Endpoints Explorer?
Visual Studio incluye una utilidad poco conocida que ahorra mucho tiempo. La encuentras en View > Other Windows > Endpoints Explorer.
Desde ahí ves todos los endpoints registrados en tu API. Haces clic derecho sobre cualquiera de ellos, eliges Generate Request y la herramienta crea automáticamente la petición correspondiente dentro del archivo .http. A medida que tu API crece y agregas más controladores, esta utilidad se vuelve clave para no escribir cada petición a mano.
¿Endpoints Explorer reemplaza a Postman? No. Es complementario y funciona dentro de Visual Studio para generar peticiones rápidas en el archivo .http, sin reemplazar las funciones avanzadas de Postman.
¿Cuándo conviene usar Postman para probar una API?
Postman ofrece una interfaz gráfica donde eliges el verbo (GET, POST, PUT, PATCH, DELETE), pegas la URL, presionas Send y recibes la respuesta con métricas como el tiempo de ejecución y el tamaño del cuerpo.
Lo que lo hace especialmente potente:
- Soporte amplio de mecanismos de autorización, prácticamente todos los estándares actuales.
- Manejo sencillo de encabezados personalizados para cada petición.
- Configuración de cuerpos JSON para verbos como POST o PATCH cuando necesitas enviar datos del recurso a crear o actualizar.
- Organización en colecciones, que agrupan peticiones relacionadas y permiten compartirlas con tu equipo.
Un buen reto: crea una colección para este curso de APIs con .NET y guarda ahí cada request que vayas aprendiendo. Tendrás un repositorio personal de pruebas listo para reutilizar.
¿Por qué falla un cliente HTML al consumir la API y qué es CORS?
Entre los recursos de la clase encuentras un archivo HTML que simula un cliente consumiendo la API. Al abrirlo, lo primero que debes ajustar dentro del <script> es la ruta: tu localhost puede tener un puerto distinto, así que actualiza esa variable antes de probar.
Con la API apagada, el cliente arroja un error de conexión, algo esperable. Pero al levantar la API y volver a intentar, aparece un mensaje en la consola que sorprende a muchos:
From origin null has been blocked by CORS policy.
Esto pasa porque el navegador bloquea por defecto las peticiones entre orígenes distintos por seguridad. La API necesita una configuración explícita llamada CORS (Cross Origin Resource Sharing) para autorizar a otros servicios web a consumirla.
¿Qué es CORS en una API? Es una política de seguridad del navegador que controla qué orígenes externos pueden hacer peticiones a tu API. Sin configurarla, cualquier cliente web distinto al servidor recibirá un bloqueo automático.
Esa configuración se resuelve del lado del servidor, dentro del propio proyecto .NET, y es justamente el punto de partida para profundizar en seguridad y exposición de servicios. ¿Ya te habías topado con un error de CORS en algún proyecto? Cuéntame en los comentarios cómo lo resolviste.
Habilidades y conceptos clave de la clase
- Archivo .http [00:18]: archivo nativo de la plantilla .NET 10 que permite ejecutar peticiones HTTP versionadas con Git.
- Variables con @ [01:34]: sintaxis para definir valores reutilizables como la URL base de la API.
- Verbos HTTP [01:48]: GET, POST, PUT, PATCH, DELETE usados para distintas operaciones sobre recursos.
- Consola Interactive [01:00]: ventana en Visual Studio para diagnosticar errores del archivo .http.
- SDK de .NET 9 [01:14]: requisito actual para que la herramienta del archivo .http funcione, aún no migrada a .NET 10.
- Endpoints Explorer [03:41]: utilidad de Visual Studio para listar y generar peticiones de los endpoints.
- Postman [04:18]: cliente gráfico para probar APIs con soporte de autorización, encabezados y cuerpos JSON.
- Colecciones de Postman [05:11]: agrupaciones de peticiones reutilizables y compartibles.
- CORS [06:48]: política de seguridad que regula el consumo de la API desde orígenes web distintos.
