.NET 6 apresenta o suporte a Minimal APIs. Embora o conceito seja relativamente novo para .NET, já está consolidado em outras plataformas.
Minimal APIs é um jeito diferente de construir APIs HTTP. Tomar a decisão de usar um novo padrão/conceito é sempre um desafio para arquitetos e desenvolvedores. Para ajudar a tomar uma decisão mais embasada, segue três ótimas razões e uma advertência.
Menos código para ler, menor custo para manter
Uncle Bob ensina que gastamos dez vezes mais tempo lendo do que escrevendo código. Em termos simples, isso significa que a cada hora trabalhada, produzimos 6 minutos de código novo. Essa proporção acontece, em grande parte, pela complexidade do que produzimos hoje. Com menos complexidade, acredita-se que a produtividade pode melhorar, e bastante. Manter serviços HTTP com menos código é um ótimo diferencial para Minimal APIs que, seguramente, irão agradar além dos times técnicos.
Suficiente para desenvolver qualquer tipo de aplicação.
Preocupado com onde ficam as regras de negócio com Minimal APIs? Não deveria. Afinal, essas regras nunca deveriam estar junto ao código que expõe a API.
Minimal APIs entregam, basicamente, o mesmo serviço HTTP que uma aplicação Web MVC padrão, porém de uma forma mais simples. As regras de negócio devem permanecer onde sempre estiveram. Não criemos confusão desnecessária. A ideia é ser simples, não “simplório”.
Não é uma “modinha”
Como já dissemos, Minimal APIs não é uma ideia nova. Python e NodeJS já possuem alternativas para esse estilo há tempos. Mesmo em .NET, já existiam alternativas viáveis, como o pacote Carter.
Serviços HTTP escritos com Minimal APIs em .NET 6 seguem um formato muito parecido quanto um serviço HTTP escrito com NodeJS + Express. Código mais simples é sinal de evolução e maturidade.
Cuidado! Minimal APIs podem induzir a “gambiarra”
Nem todo serviço HTTP pode e deveria ser implementado com Minimal APIs. Aplicações podem demandar customizações em componentes, complexas ou ainda não adaptadas para o novo estilo. Aparentemente, esse é o caso, por exemplo, de alguns cenários de Autorização e Serialização.
Forçar a natureza para utilizar Minimal APIs onde não há ferramental adequado pode conduzir a introdução de complexidade acidental, aumentando desnecessariamente os custos de manutenção. Não descarte o bom e velho MVC, pelo menos por enquanto, quando seu serviço HTTP demandar componentes mais customizados.
Conclusão
Há razões mais do que suficientes para adotar Minimal APIs. Destacamos, códigos menores e mais baratos de manter, possibilidade de continuar suportando cenários complexos de negócio e a garantia de que não se está tratando de uma “nova melhor tecnologia de todos os tempos da última semana”. Experimente, entretanto, seja responsável.
Esqueci de mencionar algo? Consegue destacar outra vantagem? Tem algum receio que não abordei? Deixe suas opiniões nos comentários.
Se precisar de ajuda para utilizar Minimal APIs do jeito certo em sua empresa, conte conosco.
