WebRequest(): Guia Definitivo para Requisições e APIs

Implementar requisições HTTP via WebRequest parece simples no papel, mas a realidade do código em produção é bem mais caótica. O problema não é disparar o comando, mas sim lidar com o que volta.

A maioria dos desenvolvedores trava quando a resposta do servidor não é um texto limpo, mas um fluxo de bytes que precisa ser decodificado manualmente enquanto a interface do usuário congela.

A fricção invisível do WebRequest

O objetivo operacional é claro: conectar sua aplicação a uma API e trocar dados. No entanto, o caminho entre o WebRequest e o JSON utilizável é cheio de armadilhas técnicas.

Configurar um GET é trivial. O gargalo real surge no POST, onde a codificação do corpo da requisição e a definição correta dos headers de Content-Type determinam se o servidor aceita o dado ou retorna um erro 400 genérico.

Há também a questão da latência. Se você não implementar o tratamento de timeouts e a assincronia corretamente, sua aplicação se torna instável ao primeiro sinal de instabilidade na rede.

Além disso, a segurança é negligenciada. Tentar conectar em endpoints HTTPS sem a configuração correta dos protocolos TLS resulta em falhas de handshake que não aparecem em tutoriais básicos de “olá mundo”.

Para quem busca estabilidade, entender a fundo a documentação técnica de requisições é o único caminho para evitar que o sistema caia em ambiente de homologação.

O WebRequest atua como a ponte bruta. Ele não “limpa” os dados para você; ele entrega a resposta bruta do servidor, exigindo que o desenvolvedor domine o tratamento de streams e a desserialização de objetos JSON.

Desenvolvedores que migram de `HttpWebRequest` para `HttpClient` frequentemente travam no gerenciamento de ciclo de vida do `HttpClientHandler`. O erro clássico não é sintaxe, mas exaustão de soquetes: instanciar `new HttpClient()` dentro de um `using` para cada chamada derruba serviços sob carga moderada. O `WebRequest` legado, apesar de verboso, forçava um padrão síncrono que mascarava assincronidade mal feita. Hoje, a expectativa é fluidez: *await* limpo, *pipeline* de *middleware* via `DelegatingHandler` e serialização nativa via `System.Text.Json`. O mercado padronizou em torno do `IHttpClientFactory` no .NET Core/5+, transformando a configuração de *timeouts*, *retry policies* (Polly) e cabeçalhos padrão em infraestrutura, não código de negócio. Quem ainda copia snippets de 2015 para chamar APIs modernas paga com latência inexplicável e *memory leaks* silenciosos. A curva de aprendizado real não é o verbo HTTP, mas o *lifecycle* do handler e a injeção de dependência tipada. Para quem precisa dominar essa transição sem refazer a arquitetura inteira, o guia técnico disponível aqui estrutura do básico ao avançado com exemplos que compilam.

Pré-requisitos e Configuração: Onde a Maioria Erra

O pré-requisito não é “saber C#”. É entender *Dependency Injection* (DI) e o padrão *Factory*. Sem isso, você injeta `HttpClient` concreto no construtor do serviço e trava testes unitários.

A configuração correta começa no `Program.cs` (ou `Startup.cs`):

• AddHttpClient: Registra o *typed client*. Injeta `HttpClient` pré-configurado com *BaseAddress* e *DefaultRequestHeaders*.
• ConfigureHttpClientDefaults (.NET 8+): Adiciona *resilience handler* padrão (retry, circuit breaker) via `Microsoft.Extensions.Http.Resilience`.
• HttpClientHandler: Controle fino de `ServerCertificateCustomValidationCallback` (apenas dev), `AutomaticDecompression`, `UseCookies`, `Proxy`.

Erro comum: definir `Timeout` no `HttpClient` global. Isso estoura requisições longas legítimas (upload de arquivo). Defina via `CancellationToken` por requisição ou `SetTimeout` em *extension method* customizado.

Depoimento real (Reddit r/dotnet): “Gastei duas semanas caçando ‘The request was canceled’ aleatório. Era o timeout default de 100s do HttpClient batendo de frente com o Polly Retry configurado para 3 tentativas de 60s. O timeout total estourava antes do retry acabar. Removi o timeout global, passei CancellationToken por request, resolvi na hora.”

Requisição GET: Desempenho Prático e Armadilhas de Stream

GET parece trivial. `await client.GetAsync(url)`. O diferencial real está no consumo da resposta.

• ReadAsStreamAsync: Essencial para desserializar JSON grande sem alocar string intermediária no LOH (Large Object Heap). Use `await JsonSerializer.DeserializeAsync(stream)`.
• EnsureSuccessStatusCode: Lança exceção em 4xx/5xx. Útil para *fail fast*, mas quebra fluxos onde 404 é estado válido (ex: verifica existência). Prefira checar `response.IsSuccessStatusCode`.
• HttpCompletionOption.ResponseHeadersRead: Retorna o controle assim que headers chegam. Permite streaming do body para disco ou desserialização paralela enquanto baixa. Crucial para arquivos > 50MB.