Introduction

Calling a controller action from jQuery usually means sending an Ajax request from the browser to a server endpoint and handling the response without a full page reload. This pattern is common in MVC-style applications where the server owns business logic and the page needs to update part of the UI asynchronously.

The basic idea is simple: expose an action on the server, send a request from jQuery, and return a response format the client can use easily, usually JSON. The important details are route matching, HTTP method choice, and validation.

A Simple Server Action

In an ASP.NET MVC-style application, a controller action that returns JSON might look like this:

1using System.Web.Mvc;
2
3public class ProductController : Controller
4{
5    [HttpGet]
6    public JsonResult Details(int id)
7    {
8        var product = new
9        {
10            Id = id,
11            Name = "Desk Lamp",
12            Price = 49.99
13        };
14
15        return Json(product, JsonRequestBehavior.AllowGet);
16    }
17}

This action accepts an id parameter and returns a JSON object. On the client side, jQuery can call it with $.ajax, $.get, or $.post depending on the request type.

Calling the Action with jQuery

Here is a basic jQuery request using $.ajax:

1<button id="load-product">Load Product</button>
2<div id="result"></div>
3
4<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
5<script>
6  $(function () {
7    $("#load-product").on("click", function () {
8      $.ajax({
9        url: "/Product/Details",
10        type: "GET",
11        data: { id: 42 },
12        success: function (response) {
13          $("#result").text(response.Name + " - $" + response.Price);
14        },
15        error: function (xhr) {
16          $("#result").text("Request failed: " + xhr.status);
17        }
18      });
19    });
20  });
21</script>

When the button is clicked, jQuery sends a GET request to /Product/Details?id=42. If the action returns JSON successfully, the callback updates the page.

Sending Data with POST

Use POST when the request changes server state, such as creating or updating data.

1using System.Web.Mvc;
2
3public class ProductController : Controller
4{
5    [HttpPost]
6    [ValidateAntiForgeryToken]
7    public JsonResult Rename(int id, string newName)
8    {
9        return Json(new { Success = true, UpdatedName = newName });
10    }
11}

Client-side code:

1<input id="new-name" value="Modern Lamp">
2<button id="rename-product">Rename</button>
3<input type="hidden" name="__RequestVerificationToken" value="TOKEN_FROM_FORM">
4
5<script>
6  $(function () {
7    $("#rename-product").on("click", function () {
8      $.ajax({
9        url: "/Product/Rename",
10        type: "POST",
11        data: {
12          id: 42,
13          newName: $("#new-name").val(),
14          __RequestVerificationToken: $("input[name='__RequestVerificationToken']").val()
15        },
16        success: function (response) {
17          console.log(response.UpdatedName);
18        }
19      });
20    });
21  });
22</script>

The anti-forgery token matters for state-changing requests in many MVC applications.

Why JSON Is Usually the Best Response Type

Controller actions can return HTML, plain text, or JSON. For jQuery-driven UI updates, JSON is often the best fit because it separates data from presentation.

That lets the browser decide how to render the response instead of coupling the controller action to a fragment of markup. It also makes debugging easier because the payload is explicit.

If you do want to return a partial view, that is possible too, but it is a different pattern from a plain JSON API call.

Route and URL Choices

The URL in the Ajax request must match the actual route configuration. Hard-coding strings works for small examples, but in real applications route helpers are safer because they reduce breakage when routes change.

Also be clear about query string versus request body semantics:

• GET requests usually send data as query parameters
• POST requests usually send data in the request body
• state-changing operations should generally not use GET

That keeps the controller contract predictable.

Common Pitfalls

One common mistake is returning a normal view from the controller while the jQuery code expects JSON. The request succeeds, but the client-side code then tries to read properties from HTML instead of a JSON object.

Another issue is sending POST requests without anti-forgery data in applications that require CSRF protection. The server may reject the request even though the JavaScript looks correct.

It is also easy to use the wrong URL. If the route does not match the action, the request fails with 404 and the problem is not in jQuery at all.

Finally, do not trust client input just because the request comes from your own page. The controller still needs validation and authorization checks.

Summary

• jQuery can call a controller action by sending an Ajax request to the correct route.
• JSON is usually the most convenient response format for asynchronous UI updates.
• Use GET for reads and POST for state-changing operations.
• Include anti-forgery protection for secured POST requests in MVC applications.
• Most failures come from route mismatches, wrong response types, or missing request validation.