|
I posted this Q/A over on StackOverflow:
http://stackoverflow.com/questions/10976762/html-routelink-to-a-web-api-route-possible detailing a scenario on my current project whereby I want to render a hyperlink to a GET operation that's handled by my Web API layer.
My solution (that I guess I'll use till it no longer works or till another better one comes along) is to exploit the fact that the Web API's HttpRoutes utilise a 'hidden' route value to determine whether route-matching should occur.
Clearly my solution is brittle since it relies on knowledge of the value of the internal constant magic string HttpRoute.HttpRouteKey. This could be made less brittle if that constant were public, however I'm thinking that we should instead have a
suite of Action/Route helpers for UrlHelper and ActionLink/RouteLink helpers for HtmlHelper that'll simplify the generation of such urls on web pages. E.g. Url.HttpRoute(*)/Url.HttpAction(*) and Html.HttpActionLink(*) and Html.HttpRouteLink(*) - second
of these could stack on the first; or simply re-use the existing Url Helpers, after the magic route key is added, as I have done on my page.
I think this is a valid use-case; initially just because of my own example of XSD schema being exported from the web API part of an MVC website - but for the UrlHelper case, consider POSTs generated from MVC Forms - where the ability to route to a different
URL, potentially handled by the Web API could be very useful.
I haven't investigated the reverse - that is, Web API code generating URIs via routing to URLs handled by the MVC handler - but I'm guessing that since the special route key only affects the web API routes, that should already work. If it doesn't,
and a decision is made to support the addition of these new MVC handlers I propose; then perhaps the same should also be done for Web API to MVC routing as well.
The only difficulty I can see at the moment would be exactly where these new extensions would be defined - placing them in either the MVC or Web API assemblies implies a cross-reference to the other - creating a dependency that doesn't at present exist.
|