ASP.Net 4 non-MVC API Route Handler Design

Question

I have an ASP.Net 4 website, non MVC, that is Forms Authenticated, and I need to equip it with an API. After googlage, it seems RESTful API would give greatest accessibility.

I already have asynchronous custom HTTP Handler code in place, for some Comet functions. I would like to use async handlers in the API, to ensure the IIS threadpool is not tied up, and to keep performance optimal.

I would like to try to stay REST faithful and use the URI to access and change resources. Are there design guides around for this kind of thing, as it seems like a task that many devs would face?

I am unsure as to whether to use one handler for the API that fires for all HTTP verbs, or one handler per resource type, or multiple handlers derived from a generic async handler. Any guidance would be appreciated.

Answer 1

In your situation, I'd just make use of Web API. It's easy to integrate with WebForms projects, and it's basically made for doing REST in ASP.NET. While the article doesn't show it, the Web API lets you use Task<> in your controllers, making it nice and async.

If you absolutely insist on keeping any and all ASP.NET MVC components out of your WebForms project—even though they're perfectly compatible with one another—then I don't know what to tell you, because doing it without MVC just seems counterproductive to me; like reinventing the wheel.