Jeg anser meg selv som en fullstackutvikler. Likevel har jeg de siste par årene jobbet aller mest med frontend, så jeg har mildt sagt ikke .NET i fingrene for tiden. For å være ærlig føler jeg aldri at jeg egentlig har hatt det. Men i høst kom en i teamet som jobber med markedsføring bort til meg og sa noe sånt som: «Jeg trenger regelmessig oppdatert data fra et åpent api, bare på et litt annet format, som datakilde til et annonseringsprogram jeg bruker. Jeg kan spesifisere datakilden som en url».

På grunn av diverse begrensninger kunne vi ikke lage dette som en enkel funksjon i skyen, som kanskje ville vært førstevalget (Lambda+API Gateway i AWS). Og organisasjonen bruker .NET. Så her luktet det å sette opp et enkelt .NET API. Men…«et enkelt .NET API? There’s no such thing», tenkte jeg. Masse boilerplate. Selv om vi bare trenger et enkelt endepunkt. Og som attpåtil kan ligge helt åpent, uten autentisering. Likevel, et .NET API med controllere virket i overkant overkill.

Men jeg lagde nå en lapp og la den nederst i backloggen med taggene “størrelse: medium” og “viktighet: medium-lav” og tenkte at den kan vi plukke opp Etterhvert™. Ikke et spesielt godt utgangspunkt for en ung og lovende tjeneste som drømmer om å reise til det forgjettede landet “Produksjon”.

«Har du hørt om “Minimal API"?»

Så en dag gikk jeg for å ta den rutinemessige etter-lunsj-kaffekoppen for å motvirke 14-knekken og kom i prat med en av infrastrukturlegendene i organisasjonen. Han kunne fortelle at det finnes en enklere måte å lage endepunkter på i .NET 7. Mindre boilerplate. Færre filer. Raskt å sette opp. Perfekt for mitt use case!

La det bli lys!

Det han snakket om var "Minimal API". Den aller enkleste veien for å teste ut dette er å huke av "Use controllers" når du oppretter et nytt .NET Core API i Visual Studio 2022, og ikke minst velge .NET 7.

Da får du et enkelt oppsett hvor med et GET-endepunkt, hvor alt skjer i Program.cs fila! 4 kodelinjer er alt som skal til - vel å merke for å sette opp det aller enkleste endepunktet man kan tenke seg, men likevel. Og med .NET 7 blir det meste abstrahert bort på magisk vis:

Er dette vanlig .NET Core?

Jepp! Med andre ord er det for eksempel relativt enkelt å skrive om til å bruke vanlig controllere hvis det viser seg at man trenger mer struktur, eller det er noen features man trenger som ikke er tilgjengelig med Minimal APIs.

Hva med dependency injection?

Mulig det også! Selv uten en konstruktør. Her er det mer .NET 7-magi som abstraherer bort det meste:

CRUD sa du?

Du gjettet riktig: i likhet med app.MapGet() finnes det støtte for resten av CRUD-metodene også. Under er et enkelt eksempel på hvordan man kan hente ut data fra body'en til en POST request mot /ønskeliste ruten:

Selve requesten og resultatet fra kallet ser da slik ut:

Hva med autentisering?

Autentisering i .NET Core gjelder også for Minimal APIs. Har man satt det opp er det bare å slenge på en [Authorize] attributt på endepunktet, på samme måte som man ville gjort på et endepunkt i en controller.

Blir det ikke fort rotete?

Joda, det kan fort bli uoversiktlig med alt i Program-fila. Men det er lett å organisere koden bedre! For eksempel ved å flytte ut selve logikken i endepunktene til egne service'er, som jeg så vidt var inne på ifm. dependency injection.

Når bør man heller gå for vanlige controllere?

Godt spørsmål! Jeg aner ikke. For mitt use case var tjenesten så liten at dette føltes helt riktig. Da med alt stappet inn i Program.cs. Og for eksempel i en mikrotjenestearkitektur kan det godt hende at dette er et godt valg for noen av tjenestene hvis funksjonaliteten er begrenset nok.

Hva med (…)? Og (…)?

Les mer her! https://learn.microsoft.com/en-us/aspnet/core/fundamentals/minimal-apis?view=aspnetcore-7.0

Ønsker du å lære mer om forskjellene mellom Minimal APIs og API med controllere kan du lese mer om det her: https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-web-api?view=aspnetcore-7.0&tabs=visual-studio#diff-v7