Is RedirectToAction in C# expensive?

Question

I've some code like the following;

We're going to create a Note but we may know the CustomerId when we do so I've two URLs;

public ActionResult CreateByCustomer(int id)                                        
{
    Session["ncAppointmentId"] = 0;
    Session["ncNoteDate"] = null;

    SetConsultant(0);
    return RedirectToAction("Create", "Note", new { id = id });
}

public ActionResult Create(int id = 0)
{
    int _CustomerId = id == 0 ? Convert.ToInt32(Session["CustomerId"]) : id;
    Session["TemplateIds"] = null;
    and so on.......
    ViewBag.CustomerId = _CustomerId;

When I look at the performance in Firebug the RedirectToAction causes a GET with a '302 Found' status which can incur up to 1 second's delay.

If I change the RedirectToAction line to

    return Create(0);

Then the GET doesn't happen and performance is improved.

But I'm looking for opinions on what the downside is or what I've missed ?

Answer 1

The RedirectToAction result tells the client to request a new page, so it will naturally incur overheads since the client is now having to make a second request to your server. Sometimes this is necessary, sometimes - as in your example - not.

Generally I use RedirectToAction to return the client to a specific page after performing an action such as creating a note. This can be useful if you're on a page that lists notes and you want to refresh the page after creating a new one. The end result is that the page is refreshed, and the Create action does not appear in the user's browser history.

If your Create method returns a View, there can be some interesting side effects of calling it directly. In general the MVC code will handle it, but you can get some weird results - like the client's URL being different to what you expect in the subsequent requests, etc. If you're OK with this, fine.

Another option would be to get rid of the CreateByCustomer action and simply call the Create view with a parameter - named customerID for instance. This gives you the same ability to call it different ways without having to have multiple entry points. The client's location would reflect (in the query string) the difference between Create and Create?customerId=12345 which may or may not be what you're after.

---

<opinion>
Some Style Notes:

• If you're storing lots of session data, create a class to hold it instead of creating lots of entries in Session[].

• It's not particularly difficult to use jQueryUI to create an in-page editor for your notes rather than defining a view - check out this example. More elegant too :P

</opinion>

Answer 2

The RedirectToAction method is going to return an HTTP response that has a Found status code and a Location URL pointing to the place you are redirecting the client. The cost is simply another GET request, which I would not consider expensive. The decision to redirect or not should be made based on whether it conceptually makes sense, not based on whether you are making one less GET request.

I don't entirely understand the motivation here, however. If you elaborate on why you are trying to redirect, maybe I can help you choose a pattern that makes more sense.

Typically, you would not name a method Create* in an HTTP API. The idiomatic, correct prefix is Post* or Put*, depending on whether you are adding a new resource (but naming it) or creating/replacing a resource (and naming it), respectively.

Answer 3

The big difference is regarding if you want the url to change to the "Create" one. If it's ok to show whatever you are showing with that url, then avoid the redirect. Redirect is useful when you have an old url and you want it to point to a new one and also in the situation when you want to avoid saving new stuff if the user refresh de page (as it will refresh only the redirect request and not the post).