I've been building a web analytics component that I want to wrap up as a NuGet package. It has an endpoint that a JavaScript tracker sends info to, much like Google Analytics, and a dashboard to view results.
I was looking at Glimpse as an example of how to build reusable ASP.Net components. Glimpse functionality is served through a Glimpse.axd HttpHandler endpoint. I was wondering why it took that approach? If it only needed to support ASP.Net MVC, would it make more sense to just use an MVC or Web API controller?
Edit: clarified that it's the mechanism, not theasy .axd extension I'm curious about.
I think you more or less already provided the answer to your question by stating
If it only needed to support ASP.Net MVC, would it make more sense to just use an MVC or Web API controller
From that point of view it seems logical to use an IHttpHandler approach as it is one of the lowest common denominators for the different web frameworks running on ASP.NET , without taking a specific dependency on those frameworks. That way you also prevent imposing the use of those frameworks onto your users, especially if they are not using them. Glimpse has a plugin model for that, allowing other features, specific to those web frameworks, to be added, but that is a decision the user has to make.
As a side note, the Glimpse HttpHandler only provides the Glimpse related resources (configuration page accessible through the Glimpse.axd, but also the Glimpse Client scripts, images, access to stored data ...). Next to the Glimpse IHttpHandler there is also a Glimpse IHttpModule that is responsible of hooking the GlimpseRuntime, which is the core of Glimpse that does all the heavy lifting, into the ASP.NET runtime.
So basically the IHttpHandler and IHttpModule implementations are only adapters for the GlimpseRuntime to make it work with ASP.NET, Glimpse also has implementations running on OWIN, Nancy, ...
Another advantage of using the IHttpHandler and IHttpModule is the Install Glimpse NuGet package(s) and you are up and running approach of Glimpse, which makes Glimpse available by only registering the HTTP Handler and HTTP module in the web.config, no additional hassle for instance with routes that need to be registered to make a Glimpse Controller accessible etc... which all of that can easily conflict with other routes defined by the hosting application, ...
TL;DR: Try to offer your reusable components, at least the core of it, with the least dependencies on web frameworks etc..., you can always provide additional packages depending on those web frameworks if they add additional features only available for those frameworks. But if your reusable component is for instance an ASP.NET MVC specific component, then that might be your common ground, just keep in mind that you, at that moment, already limit the usage of your component in other frameworks (which might be perfectly acceptable)