壮士断腕（WCF Web API），为的是 ASP.NET Web API 的横空出世，再加上它的开放（开源），于是对之产生了一点点痴情，并写下了HttpClient + ASP.NET Web API, WCF之外的另一个选择。那时，ASP.NET Web API 还处于 beta 阶段，俗话说女大十八变，自然对 ASP.NET Web API RC 产生了憧憬。。。
ASP.NET Web API RC 闪亮登场之后，还未一睹庐山真面目，就有人陆陆续续反馈之前博文中的示例代码在 ASP.NET Web API RC 版中无法正常运行。其间，我们有一个使用了 ASP.NET Web API 的项目升级至 ASP.NET Web API RC 之后也遇到了同样的问题，通过 HttpClien 将 json 格式的数据 post 给服务器之后，服务端控制器中对应的 Action 却收不到数据，错误信息为："The parameters dictionary contains a null entry for parameter ‘startId‘ of non-nullable type ‘System.Int32‘ for method..."。
开始以为是 HttpClient 的问题，之前的代码是通过 Json.NET 将需要传递的数据序列化为 json 字符串的，代码如下：
var requestJson = JsonConvert.SerializeObject(new { startId = 1, itemcount = 3 });
HttpContent httpContent = new StringContent(requestJson);
httpContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");
var httpClient = new HttpClient();
var responseJson = httpClient.PostAsync("http://localhost:9000/api/demo/sitelist", httpContent)
.Result.Content.ReadAsStringAsync().Result;
而 ASP.NET Web API RC 的改进之一是内置对 Json.NET 的支持，所以 post json 格式的数据更简单了，上面的代码可以改为：
var responseJson = new HttpClient().PostAsJsonAsync("http://test.cnblogs.cc/api/demo/sitelist",
new { startId = 1, itemcount = 3 }).Result.Content.ReadAsStringAsync().Result;
但是 HttpClient 的代码更改之后，问题依然存在，用 Fiddler 查看了一下 post 过去的数据，原汁原味正宗的 json 数据，看来问题出在服务器端。
这时，有人反馈通过 jQuery 的 $.ajax 提交 json 数据，服务端也收不到。不用想了，问题肯定出在服务端。看看示例程序的服务端代码：
public class DemoController : ApiController
{
public IList<Site> SiteList(int startId, int itemcount)
{
...
return result;
}
}
问题应该出在 RC 版本中，ASP.NET Web API 将接收到的 post 数据传统给 Action 的处理方式发生了改变。首先可以肯定的是，ASP.NET Web API RC 不可能不支持 json 参数。难道要为此定义一个类（比如这里叫SiteListQuery），将目前的参数都作为类的属性，代码如下：
public class DemoController : ApiController
{
public IList<Site> SiteList(SiteListQuery query)
{
...
return result;
}
}
public class SiteListQuery
{
public int startId { get; set; }
public int itemcount { get; set; }
}
如果真是这样，就需要定义很多这样的参数类，而且即使只有一个参数，也要定义一个类。如果真是这样，我宁愿不用 ASP.NET Web API。
当时想到这里，就没有进一步去试验，心想既然不支持常用的 json 传参方式，那就暂时不用 ASP.NET Web API RC，等正式版出来再看。
今天一位同事证实了的确需要定义一个专门的参数类，才能支持 json 传参。
当同事告诉我之后，那种爱恨交加的不是滋味的感觉就迸发出来了。怎么能这样设计，即使这样设计有它的道理，也不能放弃对通常使用方式的兼容啊。良好的兼容性是微软的发家之本，怎么在这里就被无视呢？查看 ASP.NET Web API 的源代码，这部分也没有完整的测试代码。ASP.NET 也许是微软的无心插柳，但现在柳成萌了，何不借势发展为森林呢？舍不得丢下桌面，怎能开创未来？将 ASP.NET Web Stack 开源，究竟是因为它无关紧要，还是因为真正想通过社区的力量让它发展得更好？在这样的关键时期，微软是在拿自己的劣势追赶别人的优势，还是在拿自己的优势超越别人？
痴情的不是 ASP.NET Web API，而是用更优雅的技术更好的解决实际问题；
意外的不是这个有点糟糕的设计，而且没有真正从开发者的角度去考虑。
（注：一气呵成，一吐为快，也是一种写博客的方式，写的不妥之处望见谅）