Commented Unassigned: Url.Link is ignoring route prefix when generating route [1154]

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:

```
[RoutePrefix("accounts")]
public class AccountController : ApiController
{
[HttpGet("/{accountId}", RouteName = "GetAccount")]
public IHttpActionResult GetAccount(string accountId)
{
....
}

[HttpPost]
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?

Thanks,
Attila
Comments: 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.