Adicionando lentidão e códigos de erro - Criando uma API de exemplo em C# (Curso)

Introdução à API de exemplo e sua finalidade

Tim inicia a aula reiterando a importância de ter uma API de exemplo ao aprender desenvolvimento web. Uma API desse tipo oferece algo concreto para testar suas aplicações de front-end.

Ao final do curso, Tim pretende construir uma API robusta que inclua:

• Dados de exemplo

• Documentação

• Exames de saúde

• Simulações de desaceleração

• Erros simulados

• Opções de implantação via Docker e VPS

Nesta lição específica, Tim se concentra em simular lentidões e gerar códigos de erro para um comportamento realista da API em condições adversas.

Adicionando atrasos artificiais aos endpoints da API

Tim começa adicionando um parâmetro de atraso opcional a endpoints de API específicos — particularmente aqueles que lidam com dados de cursos. Seu objetivo é simular respostas lentas de API para melhores testes de front-end.

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

Testando o mecanismo de atraso

Tim executa alguns testes usando o Postman (ou um clone do Postman) para verificar a lógica de atraso. Por exemplo:

• Um atraso de 5000 (5 segundos) faz com que a API pause antes de retornar os resultados.

• Um atraso de 500 resulta em uma pausa mais curta.

Ele observa que o atraso real será sempre ligeiramente maior do que o valor especificado devido à sobrecarga de processamento — uma nuance importante no mundo real. Como Tim observa aos 5:09 , você não está cronometrando a API até o milissegundo, mas sim simulando um limite.

Expandindo a funcionalidade de atraso para mais endpoints.

Tim não se contenta apenas com o ponto de extremidade "carregar todos os cursos". Ele busca consistência, então implementa a mesma capacidade de atraso no endpoint "carregar curso por ID".

Às 6h15 , ele se depara com um problema: um conflito de nomenclatura devido à adição automática de "Async" ao nome do método ao convertê-lo para assíncrono. Tim ajusta os nomes de ambos os métodos para que estejam em conformidade com a convenção de nomenclatura assíncrona, visando clareza e consistência.

Os testes confirmam a implementação:

• Os atrasos serão respeitados.

• Registros inexistentes retornam o código 404, como esperado, após o atraso.

• Remover o atraso ou passar valores vazios funciona corretamente, com Tim observando uma peculiaridade da interface do usuário no Postman em vez de um problema com a própria API ( 8:00 ).

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Testando o ponto final de erro

Tim agora testa o endpoint de erro passando vários códigos de status:

• 400 retorna "Solicitação inválida"

• 401 retorna "Não autorizado"

• 404 retorna "Não encontrado"

• 301 retorna "Movido permanentemente"

• 405 retorna "Método não permitido"

Isso demonstra a flexibilidade do endpoint — não apenas para códigos de erro, mas para qualquer código de status HTTP. Às 13h04 , Tim confirma que essa abordagem é ideal para testar como os aplicativos de front-end lidam com diferentes respostas do servidor.

Embora tenha considerado nomeá-lo /httpcode, ele optou por /error por simplicidade, já que é usado principalmente para simular condições de erro.

Resumo das melhorias funcionais

Tim conclui o vídeo resumindo as melhorias feitas na API:

• As reduções de velocidade simulam a latência do mundo real nas respostas da API.

• A simulação de erros oferece flexibilidade para testar praticamente qualquer resposta HTTP.

• Esses recursos tornam a API de exemplo mais robusta e indispensável para cenários de teste realistas.

Às 14h16 , Tim destaca a importância dessas ferramentas para testar o comportamento do seu aplicativo em diferentes estados da API, como respostas atrasadas ou vários erros do servidor.

O que vem a seguir: Dockerizar a API

Embora não seja abordado em detalhes neste vídeo, Tim dá a entender qual será o próximo passo: a conteinerização da API. Isso permite que os desenvolvedores executem a API de exemplo localmente em um contêiner Docker independente, facilitando a implantação e o compartilhamento em diferentes ambientes.

Considerações finais

Tim encerra o vídeo reiterando seu compromisso em construir uma API de exemplo abrangente que inclua recursos realistas que os desenvolvedores realmente precisam para realizar testes. Esses recursos incluem:

• Atrasos

• Erros

• Exames de saúde

• Planos futuros para autenticação e endpoints avançados

O objetivo é simples, mas poderoso: fornecer aos desenvolvedores uma ferramenta que imite as peculiaridades das APIs reais, para que seus aplicativos sejam robustos, confiáveis ​​e fáceis de usar.

Conclusão

Ao final desta lição, os espectadores terão uma melhor compreensão de como e por que introduzir atrasos artificiais e respostas a erros em suas APIs. A abordagem de Tim Corey é metódica, prática e diretamente ligada às necessidades de teste de aplicações reais. Se você quer aprimorar suas habilidades em testes de API, esta lição é um excelente recurso a seguir — e agora você sabe exatamente onde procurar.

Assista à videoaula completa de Tim Corey para obter orientações práticas.