How To List All Routes In A Minimal API ASP.NET Core Application

in a previous video I was showing how easy it is to get set up with minimal apis and asp.net core and in this video I want to walk us through an example scenario that I had where I needed to actually be able to list out all of the routes that were inside of my application and then later on I'm going to write tests that I can assert some information on these routes so this particular example we're going to walk through is just some code that you can use if you want to see all of the routes registered to your application so let's jump over to visual studio alright so I'm over in visual studio and this is just the weather application that gets created by default when you go make a new asp.net core application in Visual Studio the interesting thing that I want to be able to explore is that when we start using things like these minimal apis that you can see that I've highlighted here I had an interest in being able to understand all of the different routes that were registered in my application and the reason that I have this interest is because I use a lot of plug-in style architecture and I wanted my different vertical slices in my web application to be able to register their own routes now when I go to create an API that I want people to consume I wanted to enforce that I had solid API documentation and as a result I needed to be able to write tests where I could go assert all of the information about the different routes that I had in my app when I started searching online for different solutions a lot of people were saying that I could go up to the Builder or the app itself and I could start writing code that essentially I have it on my clipboard it essentially looks almost like this alright so when I was searching online for solutions for how to do this a lot of the suggestions were actually saying that we can use the app class that we have here and then we should ask the services property to be able to get the service of I endpoint route Builder and all of the information online that I could find was actually saying that if we use this we should be able to ask this service about the routes that are registered so if I go ahead and run this we'll see what happens when I step over this and I hover over the service variable it is null so unfortunately this doesn't work for me I actually even asked copilot how this works and the answer that it gave me was literally that if you want to be able to get the endpoints you must be able to have this eye endpoint route Builder service registered now I tried doing this on the app itself I tried doing this on the Builder itself and in both cases I was not getting anywhere with this the solution I found is actually something that I have on my clipboard and I'm just going to go ahead and paste it and then change the variable name because I borrowed this from another application I have and what I found actually is that asking for this particular service endpoint data source allows me to actually query all of the endpoints so one interesting thing that I want to show you is that when I put it here and I put it right after using https redirection I have it before actually registering a route and I have it before app dot run when I put it here let's go look at what this gives us back when we ask this service for the endpoints so when we do this query this early in the application startup it actually gives us back no endpoints and you might be saying well Nick that's obvious because we haven't actually registered the route yet and good point so let's go ahead and move that until after we register the route and a surprise for us is actually that even after we've registered this get route which is the weather forecast example we still get no results in our endpoints collection after asking this particular service for all of the endpoints now I am not an asp.net Guru but I thought this was kind of interesting because at this point in the life cycle I would have expected that the since the app was built and I did register a route that I should be able to get the endpoints back however what I found in practice is that if I go and put that check right after the app.run I'm actually able to get all of the routes just as expected now it's unexpected for me because I didn't think I had to run it first so one of the challenges with doing this though is that app.run is actually a blocking call so if I were to put a break point after app.run and Press Play in Visual Studio we're not going to hit that break point until we actually stop running the web server so so what can we do to get around that well if we run it asynchronously and assign it to a task we can actually await the task but before we do the await we can actually go run this code here which is just what I had above and pasted it down here instead so let's go ahead and try this out and I will run it so what we see when we actually go check this endpoints collection now is that I do have a single item in here which is our get weather forecast route and that's exactly what we'd expect because we only have a single one now a little preview for the video that I want to make right after this one is when we go inspect the metadata we can actually go see what types of properties we have configured on this route in my particular case I was interested in being able to write integration tests that prove all of the routes that I have in my application are configured as I would expect so things like rate limiting authentication all of that fun stuff and being able to do this code and actually query for all those endpoints allows me to go write those style of tests alright so that was just a super quick video for today and in this example we got to walk through how you can query for endpoints in your minimal API asp.net core application and the secret was that in this case I found that using I endpoint route Builder or whatever that interface was that everyone on the internet suggests that just doesn't work in my case that might be an MVC thing and maybe that's not anything to do with minimal apis but anyway I found that using this other class actually works in our favor but the trick to using this class was that the app actually had to be started first and I'm not sure if there's some other gotcha that I'm not aware of where you don't actually have to run the app and maybe you can fool it into getting you those routes earlier but in my particular case if I start up the app and then ask that endpoint service for the routes I'm able to get all of the information I need so in the follow-up video which I'll put right here we'll end up looking at how I wrote tests to assert all of my apis