4

I am wondering if there is a best practice for creating a REST API with ASP.NET MVC 3? At the moment I am thinking of creating a controller for each version of the REST API. For example, so far I have:

public class V1Controller : Controller
{
    public V1Controller()
    {
    }

    public ActionResult GetUser(string userId, IUserRepository userRepostory)
    {
        //code to pull data and convert to JSON string
        return View("Results");
    }

    public ActionResult GetUsersByGroup(string groupId, IUserRepository userRepostory)
    {
        //code to pull data and convert to JSON string
        return View("Results");
    }
}

Then for the views I overwrite the _ViewStart.cshtml to remove the layout and then I have Results.cshtml that just outputs the data that is formatted in the controller action, right now JSON. Having every single REST call in one controller seems like a bit too much but it is the best way I can think of so that I can keep clean separate versions of the API so that when it comes to creating version 2 of the API, I can create a V2Controller and not break the existing API to give people time to switch over to the new API.

Is there a better way to create a REST API with ASP.NET MVC 3?

IsmailS
  • 10,797
  • 21
  • 82
  • 134
ryanzec
  • 27,284
  • 38
  • 112
  • 169
  • Seems you want to ask about versioning. I think `V1Controller` is not a good practise. You mixed all the version in one `Controllers` in an MVC project. I am thinking version should be a tag/fork from a history of source control. That should not be a problem to serve REST service only but MVC contain web site+REST. So how am I publish the versioning of the REST while the web site only use the latest REST? Then I come out with creating 2 MVC projects one for web site, the other for REST service (but why not WCF?). MVC should handle both in a project, again I come back to the original thought! – CallMeLaNN Apr 22 '11 at 03:04

3 Answers3

2

I was able to find a decent solution using MVC's use of Areas.

First, I wanted to have my API follow this URL Definition:

http://[website]/[major_version]_[minor_version]/{controller}/{action}/...

I also wanted to break up the different versions in separate Project files and use the same Controller names in each version:

"../v1_0/Orders/ViewOrders/.."  => "../v2_3/Orders/ViewOrders/.."

I searched around and found a workable solution with the use of MVC Areas.

I created a new project in my solution called "Api.Controllers.v1_0" and, as a test, put a SystemController.cs file in there:

using System.Web.Mvc;

namespace Api.Controllers.v1_0
{
    public class SystemController : Controller
    {
        public ActionResult Index()
        {
            return new ContentResult() {Content = "VERSION 1.0"};
        }
    }
}

I then added a v1_0AreaRegistration.cs file:

using System.Web.Mvc;

namespace Api.Controllers.v1_0
{
    public class v1_0AreaRegistration : AreaRegistration
    {
        public override string AreaName
        {
            get{ return "v1_0";}
        }

        public override void RegisterArea(AreaRegistrationContext context)
        {
            context.MapRoute(
                "v1_0",
                "v1_0/{controller}/{action}/{id}",
                new { controller = "System", action = "Index", id = UrlParameter.Optional }
            );
        }
    }
}

I walked through the same steps above for a "..v1_1" project with the corresponding files in there, added the projects as references into my "Api.Web" MVC project and was off and running.

Aaron DeGroff
  • 21
  • 4
  • 1
    also I would add to consider having higher version controllers inherit from lower version controllers so they only need to implement behavior that has changed, instead of duplicating behavior. also consider using the same approach for model objects. – Dave Thieben Jun 07 '12 at 17:01
1

If all you are returning is JSON, you do not need a view. Jusr return 

new JsonResult(){Data = Data};

Look in here.

Also in terms of versioning, versions can be implemented as different controllers or as extra methods in the same controller. But without knowing why you would need versions and why your clients (which I assume are browsers) would need to know about versioning is not clear from your question.

Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • 2
    Well the "clients" are anyone using the API. The reasoning for the ability to have versions is in-case I make changes that force me to change the API. If I have versions of the API, that will help me negate the the possibility of breaking everyone who is using a older version of the API (not 100% but a large majority). – ryanzec Apr 12 '11 at 12:05
  • Versioning is critical in an enterprise scenario. multiple environments with multiple clients spread across an enterprise with multiple servers in a farm makes it almost necessary. – Dave Thieben Jun 07 '12 at 17:03
0

A controller such as the one you posted in your example code should always keep that methods that you have now for instance GetUsersByGroup() with the same signature. I don't see how there could be a different version of that method.

The inputs are group and repository (which I believe comes from DI). The output is a list of users in JSON format. That's all that matters to the users of the API. What you do inside this method is no one's business.

You should think more of inputs and outputs. You shouldn't be changing the signatures of existing actions unless it is really neccessary to do so.

Think of the controller class in terms of implementing the interface. You have an interface and controller class is it's implementation (I mean you don't need to have it but just think of it in that way). You will rarely change the interface once one or several classes implement it. But you might add the methods to it. And that requires only changes in implementing classes - it does not break the functionality of the API and everyone who's using it will be able to continue using it.

mare
  • 13,033
  • 24
  • 102
  • 191