https://docs.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/parameter-binding-in-aspnet-web-api
没有特殊需求的话，默认的绑定就可以使用。比如request body是json字符串。然后只要对应的class的属性和json能够对应上就可以了。
When Web API calls a method on a controller, it must set values for the parameters, a process called binding. This article describes how Web API binds parameters, and how you can customize the binding process.
By default, Web API uses the following rules to bind parameters:
- If the parameter is a "simple" type, Web API tries to get the value from the URI. Simple types include the .NET primitive types(int, bool, double, and so forth), plus TimeSpan, DateTime, Guid, decimal, and string, plus any type with a type converter that can convert from a string. (More about type converters later.)
- For complex types, Web API tries to read the value from the message body, using a media-type formatter.
For example, here is a typical Web API controller method:
HttpResponseMessage Put(int id, Product item) { ... }
The id parameter is a "simple" type, so Web API tries to get the value from the request URI.
The item parameter is a complex type, so Web API uses a media-type formatter to read the value from the request body.
To get a value from the URI, Web API looks in the route data and the URI query string.
The route data is populated when the routing system parses the URI and matches it to a route.
For more information, see Routing and Action Selection.
In the rest of this article, I'll show how you can customize the model binding process.
For complex types, however, consider using media-type formatters whenever possible.
A key principle of HTTP is that resources are sent in the message body, using content negotiation to specify the representation of the resource.
Media-type formatters were designed for exactly this purpose.
Using [FromUri]
Using [FromBody]
To force Web API to read a simple type from the request body, add the [FromBody] attribute to the parameter:
public HttpResponseMessage Post([FromBody] string name) { ... }
In this example, Web API will use a media-type formatter to read the value of name from the request body. Here is an example client request.
POST http://localhost:5076/api/values HTTP/1.1 User-Agent: Fiddler Host: localhost:5076 Content-Type: application/json Content-Length: 7 "Alice"
When a parameter has [FromBody], Web API uses the Content-Type header to select a formatter. In this example, the content type is "application/json" and the request body is a raw JSON string (not a JSON object).
At most one parameter is allowed to read from the message body. So this will not work:
// Caution: Will not work! public HttpResponseMessage Post([FromBody] int id, [FromBody] string name) { ... }
The reason for this rule is that the request body might be stored in a non-buffered stream that can only be read once.
Type Converters
Model Binders
A more flexible option than a type converter is to create a custom model binder. With a model binder, you have access to things like the HTTP request, the action description, and the raw values from the route data.
To create a model binder, implement the IModelBinder interface. This interface defines a single method, BindModel:
bool BindModel(HttpActionContext actionContext, ModelBindingContext bindingContext);
这个接口目前只能通过https://www.nuget.org/packages/Microsoft.AspNet.WebApi.Core/来获得
As for VS2017 - as said in the asp.net forums Microsoft has moved the namespace to a Nuget package called Web Api Core. In order to install it you need to typeInstall-Package Microsoft.AspNet.WebApi.Core in the Nuget Package Manager Console.
扩展阅读
Mike Stall wrote a good series of blog posts about Web API parameter binding:
- How Web API does Parameter Binding
- MVC Style parameter binding for Web API
- How to bind to custom objects in action signatures in MVC/Web API
- How to create a custom value provider in Web API
- Web API Parameter binding under the hood
Chapter 13. Formatters and Model Binding
Built-In Model Binders
The framework ships with several built-in implementations, but only three of them deserve special attention from a developer:
ModelBindingParameterBinder, FormatterParameterBinder, and HttpRequestParameterBinding, which implement completely different ways of binding a message part to a model.
The first one, ModelBindingParameterBinder, uses an approach borrowed from ASP.NET MVC in which the model is composed of different parts in the message, as if they are Lego building blocks.
The second one, FormatterParameterBinder, relies on formatters that understand all the semantics and formatting of a given media type and know how to serialize or deserialize a model applying those semantics.
Formatters represent a key part of content negotiation and are the preferred method for binding a message body to a model.
Finally, the third one, HttpRequestParameterBinding, is used for supporting scenarios with generic actions that use HttpRequestMessage or HttpResponseMessage instances directly as part of the method signature.
The framework includes a set of formatters out of the box for handling the most common media types such as form-encoded data (FormUrlEncodedMediaTypeFormatter), JSON (JsonMediaTypeFormatter), or XML (XmlMediaTypeFormatter). For other media types, you will have to write your own implementation, or use one of the many implementations provided by the open source community.
Note:
It is worth mentioning that the JsonMediaTypeFormatter implementation currently uses the Json.NET library internally to serialize/deserialize JSON payloads, and the XmlMediaTypeFormatter implementation uses either the DataContractSerializer or the XmlSerializer classes included in the .NET Framework. This class provides a Boolean property UseXmlSerializer to use the XmlSerializer class or not, which is set to false by default. You can extend these classes to use your libraries of preference for serializing XML or JSON.
Can't bind multiple parameters ('header' and 'parameters') to the request's content.
2019-01-22 16:43:53.812+08:00 ERROR [12]:
System.InvalidOperationException: Can't bind multiple parameters ('header' and 'parameters') to the request's content.
at System.Web.Http.Controllers.HttpActionBinding.ExecuteBindingAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at LISA.WebApi.Chile.Helper.CustomMessageHandler.<SendAsync>d__3.MoveNext() in C:Usersclusource
eposEdenredLISA_6.0.0.0LISA.CMS.ChileLISA.WebApi.ChileHelperCustomMessageHandler.cs:line 48
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.HttpServer.<SendAsync>d__24.MoveNext()
public string Save(JObject EmpData) { dynamic json = EmpData; A1 Emp=json.Emp.ToObject<A1>(); List<A2> EmpMarks=json.ToObject<List<A2>>(); }