Construa um Clone do Postman: Design de Biblioteca de Classes para Chamadas de API

Introdução e Configuração

Tim começa explicando o objetivo desta lição: criar a lógica de negócios e a camada de acesso a dados para fazer com que as chamadas de API funcionem no aplicativo. Ele enfatiza que este é um MVP – uma versão funcional que pode ser expandida posteriormente.

Antes de mergulhar no código, Tim observa que o curso é projetado para ser amigável para portfólios, embora ele advirta contra copiar diretamente o projeto. Em vez disso, ele incentiva os desenvolvedores a usá-lo como inspiração para criar projetos únicos que demonstrem habilidades em C#, interação com API e design de UI.

Criando a Classe de Acesso à API

Tim nos guia na abertura da biblioteca de classes e começando com uma tela limpa. Ele exclui a Class1 padrão e cria uma nova classe chamada APIAccess. Isso irá lidar com todas as interações de API.

Ele explica sua abordagem para o design de métodos: começando com métodos public void, adicionando parâmetros como string url e então refinando gradualmente para tarefas assíncronas que possam lidar com solicitações de API do 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 a criação de uma única instância de cliente HTTP para evitar reinicializá-lo a cada chamada, o que melhora o desempenho.

Manipulando Respostas de API

Uma vez que o cliente HTTP está no lugar, Tim mostra como recuperar a resposta da chamada de API. Ele aponta a importância de retornar um Task em vez de void assíncrono, exceto em manipuladores de eventos.

Para demonstrar, Tim usa uma API de exemplo do JSON Placeholder, que fornece dados falsos como postagens, comentários e todos. Ele cola o URL da API no formulário de HTML da UI e usa o campo results.Text para exibir o HTML ou JSON da resposta.

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

Tim observa que a saída de JSON bruto é legível por computador, mas não é amigável para o usuário, o que leva ao próximo passo: formatar o JSON.

Formatando a Saída JSON

Tim mostra como tornar o JSON de resposta mais legível usando JsonSerializer:

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

Isso permite que os desenvolvedores exibam JSON bonito na UI, que é mais fácil de ler em editores de texto JSON ou ao testar endpoints. Tim também adiciona uma opção para alternar entre saída bruta e formatada, dando flexibilidade dependendo se os dados serão exibidos na UI ou processados programaticamente.

Planejando para Melhorias Futuras

Mesmo que o MVP suporte apenas solicitações GET, Tim demonstra como planejar para outras ações HTTP como POST, PATCH, PUT e DELETE. Ele cria um enum chamado HTTPAction com um valor padrão de GET, preparando o código para escalar sem reescrever métodos existentes.

public enum HTTPAction
{
    GET
}

Este design de visão futura é uma ótima prática para desenvolvedores que desejam construir seu próprio clone do Postman que seja sustentável e expansível.

Validação de URL

Tim introduz um método de validação de URL para garantir que os usuários forneçam apenas endpoints 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;
}

Ele explica a importância de nunca confiar na entrada do usuário e validá-la várias vezes onde necessário. Isso garante que a aplicação não quebre devido a URLs inválidos e impede que mensagens de erro interrompam o fluxo de trabalho.

Integrando Acesso à API com a UI

Uma vez que a validação está no lugar, Tim mostra como integrar o acesso à API com a UI do painel:

1. Instanciar a classe APIAccess.

2. Validar o URL.

3. Exibir o JSON de resposta no editor de texto dos resultados.

4. Mostrar mensagens de erro significativas para solicitações inválidas ou falhadas.

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

Tim destaca a importância de um design de UI limpo, começando cada solicitação com uma área de resultados vazia e atualizando o status do sistema com base no sucesso ou falha.

Usando Interfaces para Injeção de Dependência e Teste Unitário

Tim introduz IAPIAccess, uma interface para APIAccess. Isso é uma prática recomendada para teste unitário e preparação do código para injeção de dependência:

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

Ao codificar contra uma interface em vez da classe concreta, os desenvolvedores podem substituir implementações para teste ou atualizar a lógica da API sem alterar a UI ou outro código dependente. Tim enfatiza que, embora isso seja ligeiramente excessivo para o MVP, é valioso para futuras melhorias na aplicação.

Testando e Executando a Aplicação

Com todas as peças no lugar, Tim executa a aplicação no Windows, cola o URL do JSON Placeholder e exibe com sucesso a resposta JSON formatada. Ele mostra como URLs inválidos são adequadamente rejeitados, garantindo que o aplicativo seja robusto mesmo com erros de entrada do usuário.

Isso forma um clone funcional do Postman capaz de fazer solicitações GET, validar entrada e exibir respostas em um formato amigável para o usuário.

Próximos Passos: Integração de Portfólio e GitHub

Tim encerra a lição enfatizando a importância de transformar este projeto em um item pronto para portfólio. Ele sugere:

• Criar um repositório GitHub para o projeto.

• Adicionar um README claro que explique o aplicativo.

• Incluir um executável para download para que outros possam testar.

• Destacar a interface e recursos em capturas de tela ou GIFs.

• Documentar o processo, configuração e estrutura do código.

Ele adverte contra simplesmente copiar seu código e carregá-lo como seu próprio. Em vez disso, os desenvolvedores devem usar estas lições para criar seu próprio clone do Postman ou um aplicativo semelhante que reflita estilo pessoal e conjunto de habilidades.

Ao seguir esta abordagem, os desenvolvedores não apenas demonstram proficiência em codificação, mas também mostram a capacidade de explorar, atualizar e manter um projeto de software, o que é inestimável para empregadores em potencial.

Conclusão

O vídeo de Tim Corey video oferece um guia abrangente sobre como construir um clone do Postman do zero. Desde configurar uma biblioteca de classes até manipular chamadas de API, formatar respostas JSON, validar entradas e preparar o projeto para futuras melhorias com interfaces e injeção de dependências, esta lição cobre um processo completo de desenvolvimento de aplicações.

Seguindo esta abordagem, os desenvolvedores podem criar um clone do Postman de MVP usando C# puro, integrar elementos de UI para exibir HTML ou JSON de resposta e preparar um projeto GitHub pronto para exibição em um portfólio. Esta metodologia passo a passo não só ensina código, mas também enfatiza planejamento, processo e pensamento de design, que são habilidades críticas para desenvolvedores de software profissionais.