14 KiB
| title | author | description | ms.author | ms.custom | ms.date | uid |
|---|---|---|---|---|---|---|
| Build web APIs with ASP.NET Core | scottaddie | Learn about the features available for building a web API in ASP.NET Core and when it's appropriate to use each feature. | scaddie | mvc | 01/11/2019 | web-api/index |
Build web APIs with ASP.NET Core
By Scott Addie
View or download sample code (how to download)
This document explains how to build a web API in ASP.NET Core and when it's most appropriate to use each feature.
Derive class from ControllerBase
Inherit from the xref:Microsoft.AspNetCore.Mvc.ControllerBase class in a controller that's intended to serve as a web API. For example:
::: moniker range=">= aspnetcore-2.1"
::: moniker-end
::: moniker range="<= aspnetcore-2.0"
::: moniker-end
The ControllerBase class provides access to several properties and methods. In the preceding code, examples include xref:Microsoft.AspNetCore.Mvc.ControllerBase.BadRequest(Microsoft.AspNetCore.Mvc.ModelBinding.ModelStateDictionary) and xref:Microsoft.AspNetCore.Mvc.ControllerBase.CreatedAtAction(System.String,System.Object,System.Object). These methods are called within action methods to return HTTP 400 and 201 status codes, respectively. The xref:Microsoft.AspNetCore.Mvc.ControllerBase.ModelState property, also provided by ControllerBase, is accessed to handle request model validation.
::: moniker range=">= aspnetcore-2.1"
Annotation with ApiController attribute
ASP.NET Core 2.1 introduces the [ApiController] attribute to denote a web API controller class. For example:
A compatibility version of 2.1 or later, set via xref:Microsoft.Extensions.DependencyInjection.MvcCoreMvcBuilderExtensions.SetCompatibilityVersion*, is required to use this attribute at the controller level. For example, the highlighted code in Startup.ConfigureServices sets the 2.1 compatibility flag:
For more information, see xref:mvc/compatibility-version.
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
In ASP.NET Core 2.2 or later, the [ApiController] attribute can be applied to an assembly. Annotation in this manner applies web API behavior to all controllers in the assembly. Beware that there's no way to opt out for individual controllers. As a recommendation, assembly-level attributes should be applied to the Startup class:
A compatibility version of 2.2 or later, set via xref:Microsoft.Extensions.DependencyInjection.MvcCoreMvcBuilderExtensions.SetCompatibilityVersion*, is required to use this attribute at the assembly level.
::: moniker-end
::: moniker range=">= aspnetcore-2.1"
The [ApiController] attribute is commonly coupled with ControllerBase to enable REST-specific behavior for controllers. ControllerBase provides access to methods such as xref:Microsoft.AspNetCore.Mvc.ControllerBase.NotFound* and xref:Microsoft.AspNetCore.Mvc.ControllerBase.File*.
Another approach is to create a custom base controller class annotated with the [ApiController] attribute:
The following sections describe convenience features added by the attribute.
Automatic HTTP 400 responses
Model validation errors automatically trigger an HTTP 400 response. Consequently, the following code becomes unnecessary in your actions:
Use xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.InvalidModelStateResponseFactory to customize the output of the resulting response.
Disabling the default behavior is useful when your action can recover from a model validation error. The default behavior is disabled when the xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressModelStateInvalidFilter property is set to true. Add the following code in Startup.ConfigureServices after services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_<version_number>);:
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
::: moniker-end
::: moniker range="= aspnetcore-2.1"
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
With a compatibility flag of 2.2 or later, the default response type for HTTP 400 responses is xref:Microsoft.AspNetCore.Mvc.ValidationProblemDetails. The ValidationProblemDetails type complies with the RFC 7807 specification. Set the SuppressUseValidationProblemDetailsForInvalidModelStateResponses property to true to instead return the ASP.NET Core 2.1 error format of xref:Microsoft.AspNetCore.Mvc.SerializableError. Add the following code in Startup.ConfigureServices:
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2)
.ConfigureApiBehaviorOptions(options =>
{
options
.SuppressUseValidationProblemDetailsForInvalidModelStateResponses = true;
});
::: moniker-end
::: moniker range=">= aspnetcore-2.1"
Binding source parameter inference
A binding source attribute defines the location at which an action parameter's value is found. The following binding source attributes exist:
| Attribute | Binding source |
|---|---|
| [FromBody] | Request body |
| [FromForm] | Form data in the request body |
| [FromHeader] | Request header |
| [FromQuery] | Request query string parameter |
| [FromRoute] | Route data from the current request |
| [FromServices] | The request service injected as an action parameter |
[!WARNING] Don't use
[FromRoute]when values might contain%2f(that is/).%2fwon't be unescaped to/. Use[FromQuery]if the value might contain%2f.
Without the [ApiController] attribute, binding source attributes are explicitly defined. Without [ApiController] or other binding source attributes like [FromQuery], the ASP.NET Core runtime attempts to use the complex object model binder. The complex object model binder pulls data from value providers (which have a defined order). For instance, the 'body model binder' is always opt in.
In the following example, the [FromQuery] attribute indicates that the discontinuedOnly parameter value is provided in the request URL's query string:
Inference rules are applied for the default data sources of action parameters. These rules configure the binding sources you're otherwise likely to manually apply to the action parameters. The binding source attributes behave as follows:
-
[FromBody] is inferred for complex type parameters. An exception to this rule is any complex, built-in type with a special meaning, such as xref:Microsoft.AspNetCore.Http.IFormCollection and xref:System.Threading.CancellationToken. The binding source inference code ignores those special types.
[FromBody]isn't inferred for simple types such asstringorint. Therefore, the[FromBody]attribute should be used for simple types when that functionality is needed. When an action has more than one parameter explicitly specified (via[FromBody]) or inferred as bound from the request body, an exception is thrown. For example, the following action signatures cause an exception:[!NOTE] In ASP.NET Core 2.1, collection type parameters such as lists and arrays are incorrectly inferred as [FromQuery]. [FromBody] should be used for these parameters if they are to be bound from the request body. This behavior is fixed in ASP.NET Core 2.2 or later, where collection type parameters are inferred to be bound from the body by default.
-
[FromForm] is inferred for action parameters of type xref:Microsoft.AspNetCore.Http.IFormFile and xref:Microsoft.AspNetCore.Http.IFormFileCollection. It's not inferred for any simple or user-defined types.
-
[FromRoute] is inferred for any action parameter name matching a parameter in the route template. When more than one route matches an action parameter, any route value is considered
[FromRoute]. -
[FromQuery] is inferred for any other action parameters.
The default inference rules are disabled when the xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressInferBindingSourcesForParameters property is set to true. Add the following code in Startup.ConfigureServices after services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_<version_number>);:
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
::: moniker-end
::: moniker range="= aspnetcore-2.1"
::: moniker-end
::: moniker range=">= aspnetcore-2.1"
Multipart/form-data request inference
When an action parameter is annotated with the [FromForm] attribute, the multipart/form-data request content type is inferred.
The default behavior is disabled when the xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressConsumesConstraintForFormFileParameters property is set to true.
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
Add the following code in Startup.ConfigureServices:
::: moniker-end
::: moniker range="= aspnetcore-2.1"
Add the following code in Startup.ConfigureServices after services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);:
::: moniker-end
::: moniker range=">= aspnetcore-2.1"
Attribute routing requirement
Attribute routing becomes a requirement. For example:
Actions are inaccessible via conventional routes defined in xref:Microsoft.AspNetCore.Builder.MvcApplicationBuilderExtensions.UseMvc* or by xref:Microsoft.AspNetCore.Builder.MvcApplicationBuilderExtensions.UseMvcWithDefaultRoute* in Startup.Configure.
::: moniker-end
::: moniker range=">= aspnetcore-2.2"
Problem details responses for error status codes
In ASP.NET Core 2.2 or later, MVC transforms an error result (a result with status code 400 or higher) to a result with xref:Microsoft.AspNetCore.Mvc.ProblemDetails. ProblemDetails is:
- A type based on the RFC 7807 specification.
- A standardized format for specifying machine-readable error details in an HTTP response.
Consider the following code in a controller action:
The HTTP response for NotFound has a 404 status code with a ProblemDetails body. For example:
{
type: "https://tools.ietf.org/html/rfc7231#section-6.5.4",
title: "Not Found",
status: 404,
traceId: "0HLHLV31KRN83:00000001"
}
The problem details feature requires a compatibility flag of 2.2 or later. The default behavior is disabled when the SuppressMapClientErrors property is set to true. Add the following code in Startup.ConfigureServices:
Use the ClientErrorMapping property to configure the contents of the ProblemDetails response. For example, the following code updates the type property for 404 responses:
::: moniker-end