今日起，文章系列标题名正式更名为.Net MVC4 被坑心得了！
今日修改了之前几个用ashx或aspx写的接口，其实用mvc写，直接返回JsonResult也是没什么区别的。但是既然微软推出了webapi，就尝尝味道吧。
只要去尝，就一定要被坑一坑。
首先是Request变掉了，变成了HttpRequestMessage类型，没见过的玩儿。但马上发现，Request的QueryString米有了，Form米有了，File米有了，啥都米有了，连IP都获取不了了。疼痛难忍。看来这货已经不是原始的Request了，，被层层包装了。既然Request变了，Response想来也变了。试一下，很好，Response消失了。其实，整个HttpContext基本都不存在了。
怎么办呢，网上查了资料，发现可以这样：
var SrcRequest = (HttpContextWrapper)Request.Properties["MS_HttpContext"]).Request; 来获取原来的Request。不过感觉怪怪的，完美主义在作怪么。应该还有更简单的方法吧。
试试老方法：
var SrcRequest = HttpContext.Current.Request; 好，可以用，这样还好点。
接着是路由的问题。了解Controller/id 或者 Controller?id=id会路由到Get(int id)。这已经没啥问题了，但是如果需要多参数呢？试了下，可以直接写在get方法的参数列表里，只是，如果缺少了某个参数，会返回一个错误的json数据（已经将返回设置为json格式）。这点让我很不理解，不是403或者404，也不是500，而是正常返回数据，只是返回了一串与我需要的json结构完全不同的结构的错误数据类似：
{"Message":"未找到与请求 URI“”匹配的 HTTP 资源。","MessageDetail":"在控制器“abc”上找不到与该请求匹配的操作。"}
很疼的。另外就是如果对于一些可以省略的参数怎么办呢。使用string或者int?就可以了么？ 答案是否定的。使用了可null的类型，依然阻止不了mvc报错。那么试试[Optional]特性吧，在不是必须的字段上加上这个特性，跑起来，这次报错不一样了，虽然也是报错：
{"Message":"请求无效。","MessageDetail":"对于“xxxx”中方法“result Get(Int32, Int32, Int32)”的参数“yyy”，参数字典包含无效项。字典包含一个类型“System.Reflection.Missing”的值，但参数需要的是类型“System.Int32”的值。"}
上述，将int改成int?情况一样。
好吧，换个方法试试：
public CommentListResult Get(int id, int pindex = 1, int psize = 20)
这次终于行了…… 一个小坑填完了。接着下面的坑吧
对于post方式，问题又来了。使用[FromBody]特性，只能有一个参数，否则会报错（暂时不明白，可能是body就是指请求的全部Content吧），返回500。那么，如果不用[FromBody]，全部排开，调用会如何呢？很好，返回404。又试了很多方法，总是不行。至此，我已经觉得wcf的Restful十分美妙了，webapi比起直接写controller差太多了。不过不能泄气，还是继续来吧。考虑有个方法是肯定可行的，就是不接收任何参数，然后通过原始的Request.Form来接收。但是，这样怎么看都不爽。试试其他方法。考虑会不会跟wcf一样，已经把传来的参数封装成了一个类，考虑把Request打包成一个类，然后传递。
因为只剩一个参数了，终于不报404了，也能返回。试一下，如果使用json或者xml格式传，可以传入正确值，但是用from传，传入的数据所有字段都是null……WCF正是用了Json或者xml的Content-Type来传递，才没有遇到这种问题。当然，我也曾经因为wcf的这个限制而郁闷过，使用mvc本以为会好点（事实上普通controller确实好很多，就算这个让人郁闷的webapi，其实也是比wcf要灵活一些的）。于是又一次难受起来。
恰巧看到一篇文章，写使用webapi遇到js请求跨域问题的解决方案。作者在使用了n多方案未果后，最后还是放弃了webapi，直接使用普通controller。由此有感，webapi还是有很多为考虑周全的东西。微软但凡成熟靠谱的东西，大都是收费的，但是mvc是开源的，源码拿来随便你玩不是微软喜欢干的事儿。正因为.net的mvc一直未真正成熟起来。微软从来兼容性做的都很好，但是在mvc我们发现，每一次更新和升级，都与之前的版本不兼容。折页说明mvc一直在发展和摸索。在mvc4中第一次露面的webapi，其成熟度又如何能。只有使用过才知道。
言归正传，最后还是使用HttpContext.Current.Request来获取Form的内容，然后做各种操作了。
至此，上面的get方法，为了避免传错参数而触发mvc返回默认的json错误，最好也改成这种方式。
于是，webapi的controller用着，跟普通controller和WebForm又木有任何区别了……
多对自己说“我能行，我一定可以”，
