Server e APIs no ASP.NET Core .NET 11

O papel do GitHub e dos sinais da comunidade

O principal mecanismo de sinalização continua sendo o repositório do ASP.NET Core no GitHub. Por lá, issues e discussões capturam problemas, oportunidades e propostas.

Reações como thumbs up (+1) funcionam como um indicador importante de impacto, mas não o único. O time também avalia gravidade, abrangência e se o tema bloqueia o trabalho ou é apenas desejável.

Além disso, a equipe menciona o uso de IA para analisar tendências em issues e comentários. Ainda assim, os sinais explícitos, especialmente reações e descrições de cenário, seguem como a fonte mais valiosa para decidir.

Na prática, isso muda a forma de participar da evolução do framework. Em vez de pedir funcionalidades de forma genérica, vale mais descrever cenários reais, limitações atuais e objetivos de produtividade.

Validação assíncrona no ASP.NET Core 11

No .NET 10, o time adicionou suporte nativo de validação às Minimal APIs. Segundo a documentação de novidades do ASP.NET Core no .NET 10, basta registrar o serviço com AddValidation e usar atributos de DataAnnotations.

using System.ComponentModel.DataAnnotations;

var builder = WebApplication.CreateBuilder(args);

// Registra a validação nativa das Minimal APIs (.NET 10)
builder.Services.AddValidation();

var app = builder.Build();

app.MapPost("/products", (Product product) =>
    TypedResults.Ok(product));

app.Run();

public record Product(
    [Required] string Name,
    [Range(1, 1000)] int Quantity);

Quando a validação falha, o runtime devolve um 400 Bad Request com os detalhes dos erros. O artigo sobre validação em Minimal APIs no .NET 10 mostra esse recurso em detalhes.

Contudo, essa validação funciona essencialmente de forma síncrona. Isso limita cenários reais que dependem de IO, como consultas ao banco, verificação de unicidade ou regras baseadas em dados externos.

A direção para o ASP.NET Core 11 é permitir validação assíncrona. Dessa forma, a validação se alinha a sistemas modernos, em que validar costuma exigir uma integração.

A validação fica na fronteira entre a ergonomia da API e a experiência de quem a consome. Por isso, validar bem reduz inconsistências e código duplicado.

O time também destaca um desafio histórico. O modelo clássico baseado em DataAnnotations domina o ecossistema .NET e não nasceu pensando em async.

Alterar esse comportamento pode afetar outros fluxos, como a validação de formulários no Blazor, que tradicionalmente assume um passo imediato e síncrono. Em outras palavras, a demanda existe, mas o design precisa respeitar as expectativas do stack.

Discriminated unions e o impacto nas APIs

Outro tópico de grande interesse é o suporte a discriminated unions no C#, citado como parte do planejamento do C# 15. A questão central é como esse recurso se integraria ao ASP.NET Core.

Do ponto de vista técnico, as unions resolvem um problema recorrente: endpoints que retornam um entre vários formatos válidos de resposta. Hoje, muitos desenvolvedores criam um tipo agregador com propriedades opcionais para cobrir todos os casos.

Essa solução improvisada gera ambiguidade, piora a documentação e aumenta o risco de erros no consumo. Atualmente, a alternativa nativa mais próxima é o tipo Results<...>, que declara as respostas possíveis de um endpoint.

using Microsoft.AspNetCore.Http.HttpResults;

// Abordagem atual: Results<> declara as respostas possíveis
app.MapGet("/orders/{id:int}", Results<Ok<Order>, NotFound> (int id) =>
    id == 1
        ? TypedResults.Ok(new Order(id, 150.00m))
        : TypedResults.NotFound());

public record Order(int Id, decimal TotalAmount);

Com unions na linguagem, esse tipo de modelagem pode ficar ainda mais expressivo. Na discussão, o time destacou benefícios diretos:

• Respostas mais explícitas e previsíveis.
• Documentação OpenAPI mais fiel, com vários formatos de retorno representados corretamente.
• Clientes mais seguros, porque o consumidor precisa tratar todos os casos.
• Menos campos nulos que aparecem apenas em determinadas situações.

Essa funcionalidade depende da evolução do C#. Por isso, o ASP.NET Core 11 deve acompanhar o recurso conforme ele amadurecer.

Além disso, o impacto pode chegar ao System.Text.Json, que precisaria serializar esses novos tipos. Como consequência, as camadas do framework que expõem JSON também passariam por revisão.

Para entender a proposta da linguagem, vale ler o artigo sobre union types no .NET 11.

DPoP como camada adicional de segurança

A discussão também menciona interesse no padrão DPoP (Demonstrating Proof of Possession), definido na RFC 9449. Ele adiciona uma camada extra de segurança aos fluxos de autenticação baseados em OAuth 2.0.

Com DPoP, o cliente prova que possui uma chave privada associada ao token. Assim, um token roubado perde boa parte do valor, porque o atacante não consegue gerar essa prova.

A implementação depende do componente Identity Model. Ou seja, algumas entregas do ASP.NET Core 11 dependem do ritmo de outros projetos.

Melhorias desejáveis no ecossistema de APIs

Além das prioridades consideradas obrigatórias, o time citou melhorias importantes para o ciclo:

• Suporte a atributos de validação em primary constructors.
• Inferência automática de security schemes do OpenAPI.
• Mais opções de customização do parameter binding em Minimal APIs.
• Melhor experiência com AOT e System.Text.Json, com menos falhas pouco óbvias e menos tipos declarados manualmente.

Todas essas iniciativas apontam para o mesmo objetivo. Ou seja, as Minimal APIs devem servir não apenas para começar rápido, mas também para sistemas complexos e com requisitos de governança.

Hardening do HTTP/3 no ASP.NET Core 11

O ASP.NET Core já suporta HTTP/3, mas o protocolo não vem habilitado por padrão. Hoje, você precisa ativá-lo no Kestrel, sempre com HTTPS.

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel((context, options) =>
{
    options.ListenAnyIP(5001, listenOptions =>
    {
        // HTTP/3 junto com HTTP/1.1 e HTTP/2, pois nem toda rede suporta QUIC
        listenOptions.Protocols = HttpProtocols.Http1AndHttp2AndHttp3;
        listenOptions.UseHttps();
    });
});

A meta no ASP.NET Core 11 é um trabalho de hardening. Isso inclui revisar a conformidade com as RFCs, já que parte da implementação seguiu drafts anteriores, além de ampliar a cobertura de testes.

Também entra na lista corrigir lacunas que surgem justamente porque o recurso é menos exercitado no uso padrão. Essa diretriz mostra maturidade, pois o time prefere entregar um recurso robusto antes de torná-lo padrão.

Performance de TLS em conexões curtas

Outro tema que chama atenção é a otimização do TLS, motivada por cargas internas de escala extrema. Times como o de identidade lidam com conexões muito curtas, em que o custo do handshake TLS pesa bastante.

O time citou investigações que encontraram cópias desnecessárias de dados durante o handshake. Segundo a sessão, experimentos iniciais já indicam ganhos significativos.

Esse tipo de melhoria vale muito por dois motivos:

1. Não exige nenhuma mudança no código da aplicação.
2. Beneficia de imediato qualquer serviço com alta taxa de conexões, incluindo APIs públicas e gateways.

Renovação de tokens no SignalR

O SignalR é um componente crítico para conexões persistentes. Em aplicações com bearer tokens, existe um problema conhecido: o token expira, mas a conexão pode continuar aberta por muito tempo.

A equipe reconhece que o assunto é complexo e que já houve tentativas de resolvê-lo no .NET 10. Mesmo assim, a expectativa é priorizar o tema no ASP.NET Core 11.

O impacto vai além do SignalR puro. Afinal, o Blazor Server depende do SignalR, então renovar tokens vira requisito de segurança e confiabilidade para interfaces interativas.

Passkeys no ASP.NET Core 11

O .NET 10 adicionou ao ASP.NET Core Identity o suporte a passkeys, baseado nos padrões WebAuthn e FIDO2. De acordo com a documentação de passkeys, apenas o template do Blazor Web App traz esse suporte pronto.

Para o .NET 11, o plano é trabalhar em itens complementares, especialmente em cenários sem senha. Entre os pontos discutidos estão:

• Criação de conta sem senha desde o início.
• Migração de senha para passkey depois do login.
• Integração com APIs que sinalizam quando uma passkey foi revogada.
• Endpoints que ajudem aplicativos autenticadores a converter credenciais em passkeys de forma mais automática.

Além disso, surgiu uma proposta de design importante. Em vez de ampliar a extensibilidade do MapIdentityApi, o time considera oferecer um scaffolder que gere os endpoints para você copiar e modificar.

Esse caminho é pragmático, porque uma API extensível demais fica difícil de manter. O modelo lembra a interface do Identity, personalizada por geração de código.

Por fim, segue em aberto o suporte adicional a passkeys em interfaces mais antigas, como Razor Pages. Embora o investimento principal de UI esteja no Blazor, muitos projetos continuam usando MVC e Razor Pages.