回到目錄

知識點

本文是一個很另類的文章，在項目中用的比較少，但如果項目中真的出現了這種情況，我們也需要知道如何去解決，對于知識點StringContent和FormUrlEncodedContent我們應該了解的多一點，FormUrlEncodedContent是以鍵/值對的形式進行POST數據的提供，同時要求服務端以x-www-form-urlencoded的方式去接(jie)收(shou)數據！而StringContent是ByteArrayContent的一個子集，也是MultipartFormDataContent的一個子集，在進行大數據傳輸時，我們需要使用這種方法，如果傳遞的是字符串，可以采用StringContent，如果是二進制流，可以使用ByteArrayContent，而這兩種方式都可以對外以MultipartFormDataContent的形式體現，而在服務端要以mutipart/form-data的方(fang)式來接收數據！

再深一點

multipart/form-data： 就是(shi)http請求中的(de)multipart/form-data,它會將表單的(de)數據處理(li)為(wei)一條消(xiao)息，以(yi)(yi)標簽為(wei)單元(yuan)，用分(fen)(fen)隔(ge)符(fu)分(fen)(fen)開。既(ji)(ji)可以(yi)(yi)上傳鍵值(zhi)對，也(ye)(ye)可以(yi)(yi)上傳文件(jian)(jian)。當(dang)上傳的(de)字(zi)段是(shi)文件(jian)(jian)時，會有Content-Type來表名(ming)文件(jian)(jian)類型；content-disposition，用來說明字(zi)段的(de)一些(xie)信息；由于(yu)有boundary（分(fen)(fen)隔(ge)符(fu)號）隔(ge)離，所以(yi)(yi)multipart/form-data既(ji)(ji)可以(yi)(yi)上傳文件(jian)(jian)，也(ye)(ye)可以(yi)(yi)上傳鍵值(zhi)對，它采用了鍵值(zhi)對的(de)方式，所以(yi)(yi)可以(yi)(yi)上傳多個文件(jian)(jian)。

x-www-form-urlencoded：會將表單數據轉成(cheng)鍵(jian)/值對進行(xing)傳遞，有(you)大(da)小的限制，一般是2M。

Raw:可以上傳任(ren)何格式文本，你需要(yao)顯示的說明content-type，如text/plain,text/html,text/json,text/xml等(deng)。

Binary:一般上傳文(wen)件流，它相當于content-type為(wei)application/octet-stream的情況。

從上面的介紹不難發現，raw和binary方式都屬于multipart/form-data，只(zhi)不過(guo)是兩種不同的體現而以(yi)。

DotNet平臺為WebAPI傳遞大數據

對于普通方式的HttpClient(x-www-form-urlencoded)有時已經不能滿足我們的需要了，所以必須上multipart/form-data，即在HttpClient構建時，采用StringContent的內容類型，下面是在客戶端構建一個HttpClient的方式，以服務端(webapi restful)傳遞一個大大的JSON對象！

 　　　　　　　　 var list = new List<TestApiModel>();

                entity.Category = new Category { Title = "北京" };
                entity.OrderList = new List<OrderList> 
                {
                  new OrderList{Price=1,ProductName="tel",Address=new Address {Province="印度"}},
                  new OrderList{Price=100,ProductName="tv",Address=new Address {Province="日(ri)本"}},
                  new OrderList{Price=999,ProductName="pc",Address=new Address {Province="美國"}}
                };
                for (int i = 0; i <= 100; i++)
                    list.Add(entity);

                var handler = new HttpClientHandler()
                {
                    AutomaticDecompression = System.Net.DecompressionMethods.GZip
                };
                using (var http = new HttpClient(handler))
                {
                    var body = entity.ToNameValueCollection();
                    var content = new StringContent(list.ToJson(), Encoding.UTF8, "text/json");
                    var responseResult = http.PostAsync(UriAddress, content).Result;
                }

如(ru)果(guo)客戶端采用了這種(zhong)StringContent的(de)方式，那(nei)(nei)么在設(she)計WebApi時只有兩種(zhong)選擇，第一種(zhong)就(jiu)是使用JSON強(qiang)類型(xing)（類對(dui)象(xiang)）的(de)參(can)(can)數，第二種(zhong)就(jiu)是不寫參(can)(can)數（空），如(ru)果(guo)使用string類型(xing)的(de)參(can)(can)數，那(nei)(nei)這個接口無法(fa)被找(zhao)到，即出現的(de)結果(guo)是４０４的(de)狀態碼(ma)！下(xia)面看一下(xia)服務端的(de)數據處理(li)，也是很簡單！

    public async Task<HttpResponseMessage> Post()//沒有(you)參數表示使用raw,form-data方(fang)式(shi)進行傳輸(shu)
        {
            try
            {

                var data =await Request.Content.ReadAsStringAsync();
                var entity = Lind.DDD.Utils.SerializeMemoryHelper.DeserializeFromJson<IEnumerable<TestApiModel>>(data);
             }
       //.......    

        }

上面(mian)代碼從(cong)請求上下文(wen)中(zhong)拿到了(le)這(zhe)個(ge)大(da)數據的字符串，然后通過反(fan)序列化得(de)到了(le)下面(mian)的結果：

當然，對于非常友好的(de)(de)webapi來說，你完全可(ke)以在方法(fa)參數(shu)上(shang)顯示的(de)(de)使用強類型，這種api框架會幫助我們(men)進行序列化的(de)(de)操(cao)作，真的(de)(de)很友好！

這行list對象已(yi)經被架構進(jin)行了(le)序列化操作

通過本(ben)篇文章，讓我們(men)更清楚的認識到了POST請求的幾種(zhong)方(fang)式，以及他們(men)與服務(wu)端(api)如何去結(jie)合(he)，對于java,.net平臺，這些方(fang)法都(dou)是同(tong)樣適用的！

感謝各位的(de)閱讀(du)，希(xi)望本文對(dui)你(ni)有(you)所幫助(zhu)！

回到目錄