ASP.NET Web API is Microsoft's framework (part of .NET Framework, first shipped alongside MVC 4 in 2012) for building HTTP services — plain JSON/XML APIs consumed by browsers, mobile apps, SPAs, or other servers, as opposed to full HTML pages. It gives you a controller model (ApiController), routing, model binding, and content negotiation purpose-built for HTTP semantics rather than repurposing an MVC view-rendering pipeline for JSON.

WCF can technically do REST too, but it was built around configurable bindings and SOAP-first thinking, which made plain REST/JSON feel bolted-on. Web API was built REST-first from day one. Against MVC: both share concepts (routing, filters, model binding), but MVC's ActionResult is built to return views/HTML, while Web API's IHttpActionResult is built around HTTP semantics — status codes, headers, and content negotiation are first-class, not an afterthought.

REST (Representational State Transfer) is an architectural style: resources are addressed by URLs, manipulated through standard HTTP verbs, requests carry no server-side session state, and responses use standard HTTP status codes to communicate outcome. Web API doesn't force REST on you, but its whole design — routing resources to controllers, verb-based action selection, IHttpActionResult status codes — makes building a properly RESTful API the path of least resistance.

Under convention-based routing, Web API matches the incoming HTTP verb to an action method whose name starts with that verb (GetProduct, PostProduct, DeleteProduct) — no attribute required, though [HttpGet]/[HttpPost]/etc. can override the convention explicitly, which is what attribute routing relies on instead.

public class ProductsController : ApiController
{
    private readonly IProductRepository _repo;
    public ProductsController(IProductRepository repo) => _repo = repo;

    // GET api/products
    public IEnumerable<Product> Get() => _repo.GetAll();

    // GET api/products/5
    public IHttpActionResult Get(int id)
    {
        var product = _repo.GetById(id);
        if (product == null) return NotFound();
        return Ok(product);
    }

    // POST api/products
    public IHttpActionResult Post(Product product)
    {
        _repo.Add(product);
        return Created($"api/products/{product.Id}", product);
    }
}

Every Web API controller inherits from ApiController (System.Web.Http), not MVC's Controller — a controller class must have a name ending in "Controller" for the default routing convention to find it by the {controller} route segment.

// App_Start/WebApiConfig.cs
public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();   // enable [Route]/[RoutePrefix]

        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }
}

Web API supports two routing styles side by side: convention-based (one template registered once, in WebApiConfig, matching {controller}/{id} against every request) and attribute routing (each controller/action declares its own [Route]). Attribute routing, added in Web API 2, is the modern default because it expresses nested and irregular resource URLs far more naturally than one global template can.

Once routing selects a controller, action selection happens in two possible ways: by HTTP-verb-prefixed method name convention (a GET request maps to a method starting with Get), or by explicit [HttpGet]/[HttpPost]/[Route] attributes, which always win when present. If more than one action could legally handle the same request, Web API throws an ambiguous-match error (an HTTP 500, not a 404) — a classic gotcha worth knowing distinctly from an actual missing route.

Content negotiation is Web API automatically choosing the response's wire format based on what the client says it accepts — reading the Accept header (or a ?format= query string as a fallback) and picking the matching registered MediaTypeFormatter to serialize the result. The same action, returning the same C# object, can come back as JSON to one client and XML to another with zero extra code.

JSON (via a JsonMediaTypeFormatter, historically Newtonsoft.Json-backed) and XML (via an XmlMediaTypeFormatter using DataContractSerializer) are registered out of the box, with JSON winning by default when a request has no specific Accept header. Form-url-encoded is supported for reading request bodies. Anything else — BSON, protobuf, a custom shape — has to be added explicitly as another formatter.

• Require authentication on every controller/action by default — [Authorize] applied globally, opt individual actions out with [AllowAnonymous]
• Prefer token-based auth (OAuth2 bearer tokens / JWT) over cookies for anything callable cross-origin or from non-browser clients
• Enforce HTTPS (RequireHttpsAttribute, or terminate TLS at IIS/the load balancer) and never accept credentials over plain HTTP
• Validate every model (ModelState.IsValid) before touching the database — don't trust client input
• Never bind the request body directly onto an EF entity that's then saved as-is — map through a DTO to avoid over-posting/mass-assignment