Avec .NET 9+, il est possible de créer des serveurs HTTP ultra-légers sans charger toute la stack ASP.NET. Cela permet d’intégrer une API dans une application console ou desktop (WinUI, WPF, etc.), utile pour exposer des traitements IA, des fonctions de contrôle, ou une logique métier accessible par d'autres processus.
Cet article montre comment construire une API auto-hébergée minimaliste à l’aide de Kestrel et des primitives HTTP de bas niveau.
🎯 Cas d’usage typique
- Fournir une interface JSON locale à une application desktop
- Interagir avec un moteur IA ou une base vectorielle depuis un front local
- Ouvrir une API interne pour automatiser des tests
🚀 Projet minimal
Créez un projet console :
dotnet new console -n MinimalApiApp
Ajoutez la référence à Kestrel :
dotnet add package Microsoft.AspNetCore.Server.Kestrel
⚙️ Code complet d’un serveur HTTP en C# (sans controller, sans MVC)
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
Host.CreateDefaultBuilder()
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.Configure(app =>
{
app.Run(async context =>
{
if (context.Request.Path == "/hello")
{
context.Response.ContentType = "application/json";
await context.Response.WriteAsync("{ \"message\": \"Hello from Kestrel!\" }");
}
else
{
context.Response.StatusCode = 404;
}
});
});
webBuilder.UseUrls("http://localhost:5001");
})
.Build()
.Run();
📡 Tester l’API localement
Dans un navigateur ou via curl :
curl http://localhost:5001/hello
Résultat :
{ "message": "Hello from Kestrel!" }
🧪 Ajouter une route dynamique avec un paramètre
if (context.Request.Path.StartsWithSegments("/echo", out var remaining))
{
var message = remaining.Value.Trim('/');
await context.Response.WriteAsync($"Echo: {message}");
}
Appel via : http://localhost:5001/echo/bonjour
🔐 Sécurité minimale : restreindre l’accès local
Dans certains cas, vous pouvez écouter uniquement sur 127.0.0.1 :
webBuilder.UseUrls("http://127.0.0.1:5001");
Cela empêche tout accès extérieur à la machine locale.
🧠 Bonnes pratiques
- Toujours définir un Content-Type correct (application/json recommandé)
- Protéger l’API par un token simple si exposition hors localhost
- Découper le pipeline avec Map() si les routes deviennent nombreuses
- Ne pas oublier .UseUrls() pour contrôler l’exposition
🔚 Conclusion
Kestrel peut parfaitement servir de micro-serveur local pour des applications .NET qui ont besoin d’un point d’entrée HTTP. En se passant d’ASP.NET MVC ou de Razor, on gagne en légèreté, en temps de démarrage et en clarté. Soyons francs, parfois, juste pour exposer une API simple, les choses devenaient plus proches de l'usine à gaz que d'une simple feature sympa. Car le modèle ASP.NET est fait pour beaucoup plus, et être obligé de le traîner avec soi et son projet pour une simple API est overkilling. Grâce à Kestrel on peut aujourd'hui penser à créer des API dans des Apps simples. Il faut y penser car la lourdeur d'antan a eu tendance à nous forcer à une sorte d'auto-censure ("surtout ne pas se lancer dans ce truc ça va me prendre trop de temps"). Il faut réapprendre à s'écouter et ne pas avoir peur d'ajouter ce type de comportement même à de petites ou moyennes applications sans peur du monstre ASP.NET :-) !
Stay Tuned !