C# – ASP.Net MVC ambigious action methods – why the path choosen

asp.net-mvcasp.net-mvc-3c

Is there someone who could shed a light on why ambiguous methods are not allowed in ASP.Net MVC?
I updated my question just to clarify it (using Carson63000 example from his answer), the question itself remains the same.

So, lets say we have the following action

/article/list/sport

which calls

public ActionResult List(string category) { }

and want to be able to have the following action as well:

/article/list/sport/20110904

which we would like to call accompanying method

public ActionResult List(string category, DateTime date) { }

Currently the framework throws an AmbiguousMatchException since it found two methods called List. That's the only reason for throwing the exception, that more than one method with was found that matches the actions name.

After the framework has figured out what method to use and decided that it is not ambigious, it will then try to map the supplied data from the request to the parameters of the method. Why not do this the other way around? First get all applicable methods, and then try to find the best fit by mapping parameters.

If ambiguous methods where allowed, I think the following is still possible to do.
Given that /article/list/sport uses the route /{controller}/{action}/{category} and that /article/list/sport/20110903 uses the route /{controller}/{action}/{category}/{date}
it would then still be possible to map data for url /article/list/sport?date=20110903 since it will match the route for just category, but can still map the data for method public ActionResult List(string category, DateTime date) { }.

At the moment I fail to see the reason for not allowing ambiguous methods from a design perspective. The only thing I can think of myself is that it will slow down the framework too much, and therefor the current solution is the more logical one. Or am I missing another point here?

Best Answer

If I understand your question correctly, I would say it is because you generally don't have explicit control over the parameters passed to an action.

Remember that the model binding will, by default, take them from a number of different places, including ones that are outside your control, like querystring.

It sounds like you're thinking that you should be able to have something like this:

/article/list/sport

Which calls ArticleController.List(string category);

And also:

/article/list/sport/20110901

Which calls ArticleController.List(string category, DateTime date);

But what happens when someone types the URL /article/list/sport?date=20110902 ?

It just sounds like a recipe for unpredictable behaviour, and in return, what real benefit would you get from this sort of action overloading?

Related Solutions

Telerik ASP.NET MVC components licensing

For most situations, AGPL is the only GPL license that requires releasing the source code of hosted web applications. Under vanilla GPLv2, if you're not distributing the modified and compiled binaries to end users you do not need to release the source code. You're not distributing the software, you're allowing remote access to it.

Dealing with API and Error Messages – Best Practices

I do like this approach, it is totally acceptable.

Take a look at the Flickr API. They are using error codes and error messages in their api response too.

http://www.flickr.com/services/api/

http://www.flickr.com/services/api/flickr.activity.userComments.html (example api method)

Serving error codes and error messages instead of exceptions is imho much better when dealing with multiple (unknown) client frameworks (.net, java, etc..) If an client api-implementation is wrong because it is using a wrong format, it's much better to display the error message from the server ("Invalid date format. Must be ddMMyyy.") instead of getting an weird "FormatException" (+stacktrace).

Having error ids and error messages:

improves api usability
improves maintainability
improves user / developer experience

API User(Developer) could reference easily to their problem and that will save your time. It would be much easier for you to track down a possible bug/taskswith a specific errorId/errorMessage instead of having "Hey, I'm getting those weird Exceptions when calling XYZ. What am I doing wrong?"

Edit based upon request:

Let's say we have a "BaseResponse" (similar to your APIResponse, comments are stripped out for better readability)

public class BaseResponse
{
  public int ErrorId { get; set; }

  public string ErrorMessage { get; set; }

  public bool Successful { get; set; }
}

And we're having an GetDocumentResponse (implemented by DocumentService, see below)

public sealed class GetDocumentsResponse : BaseResponse
{
   public IList<Document> Documents { get; set; }
}

DocumentService Contract

[ServiceContract]
public interface IDocumentService
{
    [OperationContract]
    [WebInvoke(
         Method = "POST",
         BodyStyle = WebMessageBodyStyle.WrappedRequest,
         ResponseFormat = WebMessageFormat.Json,
         RequestFormat = WebMessageFormat.Json)]
    GetDocumentsResponse GetDocuments(string date);
}

DocumentService Implementation (simplified)

public GetDocumentsResponse GetDocuments(string date)
{
     bool isFormatValid = // parse Date
     if (!isFormatValid)
     {
        // Response = static class, provides generic responses and sets properties of response
        return Response.ProvideFault<GetDocumentsResponse>(100, "The date-format is not valid. Valid: mmddyyyy");
        // return new GetDocumentsResponse { Successful = false, ErrorId: 100, ErrorMessage = "The date-format is not valid. Valid: mmddyyyy"};
     }

     var documents = this.documentRepository.GetDocuments(...)
     return new GetDocumentsResponse { Successful = true, Documents = documents };
}

So, let's say I'm a developer and I want to use this api.

1. - Making an valid api call & getting an valid response from server (JSON Response)

{
   "ErrorId":0,
   "ErrorMessage":null,
   "Successful":true,
   "Documents":[
      {
         "DocumentId":13,
         "Name":"xyz"
      }
   ]
}

2. - Making an invalid api call & getting an invalid response from server

{
   "ErrorId":100,
   "ErrorMessage":"The date-format is invalid. Valid: mmddyyyy",
   "Successful":false,
   "Documents":[

   ]
}

So, for the first call I've done everything right.
The second call says clearly what is wrong, I do not have to research some .NET specific exceptions (or better: wcf faults) if I'm a java developer. In a few seconds after getting the response I do know what went wrong and why it went wrong. I do not have to research documentation or much worse to ask YOU about the current implementation of GetDocuments and why my date format is invalid. It saves you and me a lot of time.

Best Answer

Related Solutions

Telerik ASP.NET MVC components licensing

Dealing with API and Error Messages – Best Practices

Related Topic