比如 public Users Get(int id) ，它可以使用兩種方式獲取：

 

api/default/5

$.get("/api/default",{id:90}, function (data) {/* 處理邏輯 */});

前者不需要注明參數(shù)名，后者適用于存在多個(gè)簡(jiǎn)單參數(shù)的情況，例如比較實(shí)際的案例以及對(duì)應(yīng)的獲取方式是：

 

public Users Get(int id, int id2)

$.get("/api/default",{id:90,id2:88}, function (data) {});

二，簡(jiǎn)單類型傳值中涉及到string的傳遞

 

對(duì)于簡(jiǎn)單類型的參數(shù)傳值，唯一有一點(diǎn)可以稱得上是問題的問題，便是遇到例如：public string Post(string v) 這樣的情況，如果你直接post一個(gè)參數(shù)名為v的字符串過去，例如：$.post("/api/testString",{ v: "i want testString" }, function (data) {}); ，那么結(jié)果是無功而返的：

 

 

 

 

通過搜索stackoverflow以及encosia（詳見這里），下面是解決方案：

 

首先為參數(shù)覆蓋上[FromBody]特性，比如 public string Post([FromBody]string v)，然后：

 

解決方案1：$.post("/api/testString", "=i want testString" , function (data) {}); //在前面加一個(gè)等于號(hào)

解決方案2：$.post("/api/testString",{ "": "i want testString" }, function (data) {}); //傳遞一個(gè)空參數(shù)名

問題是解決了，可是本人也嘮叨一句：這像什么話。

 

誠然道有些朋友會(huì)說“Web API不是這樣使用的，它是為某某某情況……你應(yīng)該構(gòu)造一個(gè)對(duì)象……”，但是，既然存在如此的使用情況，本文所針對(duì)就是可能出現(xiàn)的問題而作出解決方案。

 

 

 

三，傳遞復(fù)雜類型：

 

首先定義兩個(gè)類型，

 

    public class Users

    {

        public int uid { get; set; }

 

        public string username { get; set; }

    }

    public class DoubleStringPRameter

    {

        public string Pram1 { get; set; }

 

        public string Pram2 { get; set; }

    }

對(duì)于需要發(fā)送兩個(gè)字符串參數(shù)的情況，必須傳遞一個(gè)對(duì)象了：

 

public string Post(DoubleStringPrameter pram)

$.post("/api/testStringUsingObject", { Pram1: "參數(shù)1的值", Pram2: "參數(shù)2的值" }, function (data) {}); //不需要指定參數(shù)名

而對(duì)于需要傳遞更加復(fù)雜的對(duì)象，例如同時(shí)傳遞 DoubleStringPrameter 和 Users ，就需要這么封裝：

 

 

 

 

    public class using2ObjController : ApiController

    { 

        public string Post(IMultiObj obj)

        {

            return "uid:" + obj.User.uid + ",username:" + obj.User.username + "||pram1:" + 

                obj.StringPrameter.Pram1 + ",pram2:" + obj.StringPrameter.Pram2;

        } 

    }

 

    public class IMultiObj //定義一個(gè)類型封裝

    {

        public DoubleStringPrameter StringPrameter { get; set; }

 

        public Users User { get; set; }

    }

 

 

 

然后這么傳遞：

 

      $.post("/api/using2Obj", { User: { uid: '80909', username: 'amazon' }, StringPrameter: { Pram1: '參數(shù)1的值', Pram2: '參數(shù)2的值' } },

 

　　function (data) {});

 

 

 

 

 

對(duì)于簡(jiǎn)單類型傳值中涉及到string的傳遞，本人的意見是：作為一個(gè)API，如果提供了某些功能，那么就必須實(shí)現(xiàn)，如果做不到或者不愿意做，就應(yīng)該在編譯期間斷絕問題發(fā)生的可能（就不應(yīng)該讓 Post(string a)、Post(string a, string b)、Post(Users  u1, Users u2) 通過編譯），而不應(yīng)是在使用期間采取對(duì)用戶做出 “方言” 級(jí)的限制，這已經(jīng)有違強(qiáng)類型語言的設(shè)計(jì)初衷，試想這樣的情況：某一夜某個(gè)零時(shí)工打瞌睡寫了Post(Users  user, Content content)，編譯過去了，一個(gè)月后客戶端那邊都已做了2萬行代碼，到時(shí)候才說不能這樣使用（不能用你還寫出來干什么），這便是設(shè)計(jì)上的失職了。

 

如今這些不是問題的問題在2.0上依然存在，它既是Bug，同時(shí)也不是Bug。

 

對(duì)此本人更偏向于使用WCF或MVC的return Json()，出于Web API的問題本身，而作此文。