Url.Link is ignoring route prefix when generating route


I'm working with the nightly builds and hit a bug during url generation.

I'm leveraging the new CreatedAtRoute method to return a proper 201 response to the caller, and its internally using Uri.Link to generate the link to the given resource.

Here is the controller:
    public class AccountController : ApiController
        [HttpGet("/{accountId}", RouteName = "GetAccount")]
        public IHttpActionResult GetAccount(string accountId)

        public IHttpActionResult CreateAccount(DTO.NewAccount account)
               // Link generation happens here
The link I'm getting is http://localhost/1 instead of http://localhost/accounts/1 which should be the expected.

The other strange thing that happens is the route naming. IIRC there was a rule that when attribute based is used, you can use the <controllername>.<methodname> as route name parameter during link generation.

Now as I checked the route table I only saw Account1, Account2, Account3, etc route names, which is not giving the opportunity to generate routes by the convention above.

As a quick tip after I typed in the bug above something came into my mind. What is the url generation is just went wrong, because of the leading / in the method's url template, and I was right.

If I update the url template like this:
        [HttpGet("{accountId}", RouteName = "GetAccount")]
then the generated url will be fine, although I still think that it should be working with a leading slash too, what do you think?

Closed Jul 22, 2013 at 8:12 PM by eilonlipton

We ended up reverting the logic for the trailing slash because it causes exactly this type of confusion. We are instead making a change where if the route starts with "~/" it will ignore the various route prefixes. This way it is much more explicit.



kichalla wrote Jul 21, 2013 at 6:08 PM

First, thanks for trying out our latest bits. We really appreciate it and are looking forward for this kind of feedback!

Regarding your questions:
  1. Generated Uri.Link : This is an expected behavior due to a change that was checked in couple of days back as part of fix for bug #1150. As part of this fix, having '/' prefix on a route template decorated on an action will ignore the route prefix attribute.
  2. Route Names: We do not expect end users to depend on the auto-generated route names from attribute routing. Users can provide a more friendly route name and use it to generate the links.

attilah wrote Jul 21, 2013 at 9:07 PM

Regarding 1 it makes sense, after the update of my code (removing the forward slash) and saw that working it was my only thought, that it is by design, but since I was not sure I posted it :-) The lack of documentation at this point makes harder the dogfooding :-)

Regarding 2 it should be a good thing to have a default convention to refer to the routes (like the one I mentioned), since for a CRUD api for a large system it can be really "antiDRY" to assign route names for the routes you need to have a link generation requirements.

IIRC in WebApi 1 it worked.