ASP. NET WebAPI RC does not support the most commonly used JSON parameters

The Broken wrist (WCF Web API), in order for the ASP. NET Web API to come out, plus its open (open source), so a little bit of infatuation, and write down the httpclient + ASP. NET Web API, another alternative to WCF. At that time, the ASP is still in beta, as the saying goes, the 18 change, naturally to ASP. NET Web API RC has a vision ...

NET Web API RC after the debut, not yet a glimpse of the truth, there is a succession of feedback before the blog post sample code in ASP. NET WEB API RC version does not work correctly. In the meantime, we had the same problem with a project that used the ASP. NET Web API RC, and then the same thing happened after Httpclien the JSON-formatted data to the server, the corresponding Action in the service-side controller But the data is not received, the error message is: "The parameters dictionary contains a null entry for parameter ' Startid ' of non-nullable type ' System.Int32 ' For method ... ".

Starting with the thought of being a HttpClient, the code for the previous code is to serialize the data that needs to be passed into a Json string by Json.NET, as follows:

var Requestjson = Jsonconvert.serializeobject (New {Startid =1, ItemCount = 3}); Httpcontent httpcontent = new Stringcontent ( Requestjson); httpContent.Headers.ContentType = new Mediatypeheadervalue ( "application/json ) ; var httpClient = newvar Responsejson = Httpclient.postasync (http://localhost:9000/api/demo/sitelist "                

One of the improvements to the ASP. NET Web API RC is the built-in support for Json.NET, so the post Json-formatted data is simpler, and the code above can be changed to:

New HttpClient (). Postasjsonasync ("http://test.cnblogs.cc/api/demo/sitelist",3}). Result.Content.ReadAsStringAsync (). Result;    

However, after the HttpClient code changes, the problem still exists, using Fiddler to view the post past data, authentic JSON data, it seems that the problem is on the server side.

At this point, there is feedback from the $.ajax of JQuery to submit JSON data, the server can not receive. Don't think about it, the problem is definitely on the service side. Look at the service-side code of the sample program:

Class democontroller:apicontroller{public    ilist<site> sitelist (intreturn result;}} 

The problem should be in the RC version, where the ASP. NET Web API will receive post data that has traditionally been handled differently by the Action. The first thing to be sure is that the ASP. NET Web API RC cannot support JSON parameters. Do you want to define a class for this (for example, called sitelistquery), and use the current parameters as the properties of the class, the code is as follows:

 public class democontroller:apicontroller{public ilist<site>         Sitelist (sitelistquery query) {... return result;}} public classpublic int startid {get; setpublic int itemcount {set       

If this is the case, you need to define a number of such parameter classes, and even if there is only one parameter, define a class. If that's the case, I'd rather not have ASP.

At that time, there is no further testing, thinking that since the usual JSON transfer method is not supported, then temporarily do not use the ASP, and so on the official version of the Web API.

Today, a colleague confirms that it is necessary to define a special parameter class to support JSON parameters.

When my co-workers told me, the feeling of love and hate was not the taste of the feelings burst out. How can this design, even if the design has its reason, can not give up the usual use of the way of compatibility ah. Good compatibility is Microsoft's rich, how to be ignored here? View the source code for the ASP, which does not have a complete test code. ASP. NET may be Microsoft's unintentional insertion willow, but now Yoosung Moe, why not occasion develop into the forest? Reluctant to leave the table, how can create the future? Is it not important to open an ASP. NET Web Stack because it doesn't matter, or does it really want to make it better through the power of the community? At such a critical time, is Microsoft taking advantage of its own disadvantage, or is it taking advantage of itself to surpass others?

Infatuation is not the ASP. NET Web API, but more elegant technology to better solve practical problems;

The unexpected is not this somewhat bad design, and not really from the developer's point of view.

(Note: one go, chest, is also a way to write a blog, write the wrong place to look at forgive)

ASP. NET WebAPI RC does not support the most commonly used JSON parameters