Construye un Clon de Postman: Diseño de Biblioteca de Clases para Llamadas API

Introducción y Configuración

Tim comienza explicando el objetivo de esta lección: crear la lógica de negocio y la capa de acceso a datos para que las llamadas API funcionen en la aplicación. Enfatiza que este es un MVP, una versión funcional que puede expandirse más tarde.

Antes de sumergirse en el código, Tim señala que el curso está diseñado para ser amigable para portafolios, aunque advierte en contra de copiar directamente el proyecto. En cambio, alienta a los desarrolladores a usarlo como inspiración para crear proyectos únicos que demuestren habilidades en C#, interacción con API, y diseño de UI.

Creando la Clase de Acceso a API

Tim nos guía en la apertura de la biblioteca de clases y comenzando desde cero. Elimina la clase predeterminada Class1 y crea una nueva clase llamada APIAccess. Esto manejará todas las interacciones con la API.

Explica su enfoque para el diseño de métodos: comenzando con métodos public void, agregando parámetros como string url, y luego refinándolos gradualmente en tareas async que puedan manejar solicitudes de API del mundo real.

public class APIAccess
{
    private readonly HttpClient client = new();

    public async Task<string> CallApiAsync(string url)
    {
        var response = await client.GetAsync(url);
        if (response.IsSuccessStatusCode)
        {
            return await response.Content.ReadAsStringAsync();
        }
        return $"error: {response.StatusCode}";
    }
}

Tim enfatiza la creación de una única instancia de cliente HTTP para evitar reinicializarlo con cada llamada, lo que mejora el rendimiento.

Manejando las Respuestas de la API

Una vez que el cliente HTTP está en su lugar, Tim muestra cómo recuperar la respuesta de la llamada API. Destaca la importancia de retornar un Task en lugar de async void, excepto en los manejadores de eventos.

Para demostrar, Tim utiliza una muestra de API de JSON Placeholder, que proporciona datos falsos como publicaciones, comentarios y tareas. Pega la URL de la API en el formulario HTML de la UI y usa el campo results.Text para mostrar la respuesta HTML o JSON.

results.Text = await api.CallApiAsync(apiText.Text);

Tim señala que la salida JSON sin procesar es legible por computadora pero no amigable para el usuario, lo que lleva al siguiente paso: formatear el JSON.

Formateando la Salida JSON

Tim muestra cómo hacer que el JSON de respuesta sea más legible usando JsonSerializer:

var jsonElement = JsonSerializer.Deserialize<JsonElement>(responseJson);
var prettyJson = JsonSerializer.Serialize(jsonElement, new JsonSerializerOptions { WriteIndented = true });

Esto permite a los desarrolladores mostrar JSON bonito en la UI, lo cual es más fácil de leer en editores de texto JSON o al probar puntos finales. Tim también agrega una opción para alternar entre salida en bruto y salida formateada, proporcionando flexibilidad dependiendo de si los datos se mostrarán en la UI o se procesarán programáticamente.

Planificando para Mejoras Futuras

Aunque el MVP solo soporta solicitudes GET, Tim demuestra cómo planear para otras acciones HTTP como POST, PATCH, PUT y DELETE. Crea un enum llamado HTTPAction con un valor predeterminado de GET, preparando el código para escalar sin reescribir métodos existentes.

public enum HTTPAction
{
    GET
}

Este diseño prospectivo es una gran práctica para los desarrolladores que desean construir su propio clon de Postman que sea mantenible y expandible.

Validación de URLs

Tim introduce un método de validación de URL para asegurar que los usuarios solo proporcionen puntos finales HTTPS válidos:

public bool IsValidURL(string url)
{
    if (string.IsNullOrWhiteSpace(url)) return false;
    return Uri.TryCreate(url, UriKind.Absolute, out Uri uriResult) && uriResult.Scheme == Uri.UriSchemeHttps;
}

Explica la importancia de no confiar nunca en la entrada del usuario y validarla múltiples veces donde sea necesario. Esto asegura que la aplicación no se rompa debido a URLs no válidas y previene que los mensajes de error interrumpan el flujo de trabajo.

Integración del Acceso a API con la UI

Una vez que la validación está en su lugar, Tim muestra cómo integrar el acceso a API con el panel de control de UI:

1. Instanciar la clase APIAccess.

2. Validar la URL.

3. Mostrar el JSON de respuesta en el editor de texto de resultados.

4. Mostrar mensajes de error significativos para solicitudes no válidas o fallidas.

if (!api.IsValidURL(apiText.Text))
{
    systemStatus.Text = "URL no válida";
    results.Text = string.Empty;
    return;
}
results.Text = await api.CallApiAsync(apiText.Text);

Tim destaca la importancia de un diseño de UI limpio, comenzando cada solicitud con un área de resultados vacía y actualizando el estado del sistema basándose en el éxito o fracaso.

Usando Interfaces para Inyección de Dependencias y Pruebas Unitarias

Tim presenta IAPIAccess, una interfaz para APIAccess. Esto es una mejor práctica para pruebas unitarias y preparar el código para la inyección de dependencias:

public interface IAPIAccess
{
    Task<string> CallApiAsync(string url);
    bool IsValidURL(string url);
}

Al codificar contra una interfaz en lugar de la clase concreta, los desarrolladores pueden intercambiar implementaciones para pruebas o mejorar la lógica API sin cambiar la UI u otro código dependiente. Tim enfatiza que, aunque esto es ligeramente excesivo para el MVP, es valioso para mejoras futuras de la aplicación.

Pruebas y Ejecución de la Aplicación

Con todas las piezas en su lugar, Tim ejecuta la aplicación en Windows, pega la URL de JSON Placeholder y muestra exitosamente la respuesta JSON formateada. Muestra cómo las URLs no válidas son rechazadas correctamente, asegurando que la aplicación sea robusta incluso con errores de entrada del usuario.

Esto forma un clon funcional de Postman capaz de hacer solicitudes GET, validar la entrada y mostrar las respuestas en un formato amigable para el usuario.

Próximos Pasos: Integración de Portafolio y GitHub

Tim cierra la lección enfatizando la importancia de convertir este proyecto en un elemento listo para el portafolio. Sugiere:

• Crear un repositorio de GitHub para el proyecto.

• Agregar un README claro que explique la aplicación.

• Incluir un ejecutable descargable para que otros lo prueben.

• Destacar la UI y características en capturas de pantalla o GIFs.

• Documentar el proceso, configuración y estructura del código.

Advierte en contra de simplemente copiar su código y subirlo como propio. En cambio, los desarrolladores deben usar estas lecciones para crear su propio clon de Postman o una aplicación similar que refleje el estilo personal y el conjunto de habilidades.

Al seguir este enfoque, los desarrolladores no solo demuestran competencia en programación, sino que también muestran la capacidad de explorar, actualizar, y mantener un proyecto de software, lo cual es invaluable para posibles empleadores.

Conclusión

El video de Tim Corey proporciona una guía completa para construir un clon de Postman desde cero. Desde configurar una biblioteca de clases hasta manejar llamadas API, formatear respuestas JSON, validar ingreso, y preparar el proyecto para mejoras futuras con interfaces e inyección de dependencias, esta lección cubre un proceso completo de desarrollo de aplicaciones.

Al seguir este enfoque, los desarrolladores pueden crear un clon de Postman MVP usando C# simple, integrar elementos de UI para mostrar respuesta HTML o JSON, y preparar un proyecto de GitHub listo para presentarse en un portafolio. Esta metodología paso a paso no solo enseña código sino que también enfatiza la planificación, proceso, y el pensamiento de diseño, que son habilidades críticas para desarrolladores de software profesionales.