2012-09-04 60 views
14

我有被傳遞文件ID的列表,並返回這些文件縮略圖的ASP.NET MVC 4網絡API控制方法。從單個WebApi方法提供多個二進制文件的最佳方式是什麼?

因此,客戶端可能會通過在數字ID列表(例如10,303,29),並且該方法返回一個列表,其中一個ThumbnailImage看起來有點像這樣:

class ThumbnailImage 
{ 
    public int Id { get; set; } 
    // Some other stuff 
    public byte[] RawData { get; set; } 
} 

的原因,在調用者傳遞的ID,而不是讓每個項目的一個電話應該有希望是顯而易見的名單 - 可能有數十或數百個項目來下載的,我試圖避免將需要單獨下載他們所有的HTTP流量。

目前,我正在使用RestSharp和JSON.NET,因此我的ThumbnailImage對象正在作爲JSON通過導線傳遞。從編碼簡單的角度來看,這很好,但JSON並不是表示二進制數據的有效方式。

所以,我想我應該返回原始字節作爲八位字節流......但是,雖然我可以很容易地做到這一點的單個圖像,我不知道最好的方式來做到這一點對於多個圖像,特別是當我還需要返回每個文件的ID和其他信息時。 (該ID是必需的,因爲結果不一定會以給定順序返回 - 並且某些文件可能會丟失)。

可以簡單地零碎寫入到一切響應流,使得對於每個項我寫的ID(適當地編碼的),隨後將圖像數據的長度,然後由圖像數據本身,然後接着通過爲下一個項目同樣的事情,等

來電者會然後只需保持從流的ID讀取,直到它被耗盡,使得關於編碼假設(和長度!)等

我認爲這會奏效,但看起來很笨重 - 有沒有更好的方法?

+0

怎麼會客戶是否使用圖像?是在網頁中顯示圖像還是作爲檔案下載?其他? – EBarr

+0

想知道是否可以將響應作爲MultipartContent發送,其中內容可以是StreamContent,其中包含原始字節流。 –

+0

@EBarr:我也在編寫客戶端應用程序,所以它是一個封閉的環境。我將在WinForms應用程序中顯示圖像(作爲搜索結果縮略圖) –

回答

10

好的,這裏有一段代碼似乎工作,使用KiranChalla提到的MultipartContent。(這只是一個虛擬的示例,演示如何使用JSON編碼的「對象」(在這種情況下,僅僅是一個整數ID列表)返回兩個不同類型的文件,結合。

public HttpResponseMessage Get() 
{ 
    var content = new MultipartContent(); 
    var ids = new List<int>() { 1, 2 }; 

    var objectContent = new ObjectContent<List<int>>(ids, new System.Net.Http.Formatting.JsonMediaTypeFormatter()); 
    content.Add(objectContent); 

    var file1Content = new StreamContent(new FileStream(@"c:\temp\desert.jpg", FileMode.Open)); 
    file1Content.Headers.ContentType = System.Net.Http.Headers.MediaTypeHeaderValue.Parse("image/jpeg"); 
    content.Add(file1Content); 

    var file2Content = new StreamContent(new FileStream(@"c:\temp\test.txt", FileMode.Open)); 
    file2Content.Headers.ContentType = System.Net.Http.Headers.MediaTypeHeaderValue.Parse("text/plain"); 
    content.Add(file2Content); 

    var response = new HttpResponseMessage(); 
    response.Content = content; 
    return response; 
} 
+2

它不適合我。它只返回一個不是有效格式的文件。請幫幫我。我堅持這一點 –

0

你可以從所有的縮略圖創建一個壓縮文件(例如ZIP文件),併發送回。

然後調用者只需將其解壓縮到最後 - 發送包含多個文件的單個文件將更加可接受,然後在單個流中發送多個文件。

缺點是你不太可能利用緩存(當然取決於你的使用模式)。

+0

但是,我仍然有同樣的問題(儘管在不同的地方)傳遞所有相關信息(例如ID)......另外,我真的不明白爲什麼解壓縮ZIP比解壓縮更容易解壓縮連接的文件流? –

+1

@GaryMcGill'ZIP'被廣泛使用。它不僅可以壓縮,而且還可以用作多個文件的流式容器格式。您可以將包含相關信息的「文件」作爲您的第一個文件,並將實際文件的ID用作文件名。如果您使用ZIP的'Store'壓縮模式,它將實際上是您在問題中描述的'name,length,bytes'方案。 –

1

一個挑戰我看到的是,基於發送圖像的數量回調用者必須調整自己的超時值。如果這是一家書店,可能會有很多圖像被送回。

如果你只是發回的網址爲每個圖像,並把它留給調用者獲得實際的形象呢?這意味着多次呼叫會帶來更多的流量,但呼叫者會比以後更快地獲取信息,然後根據呼叫者的要求獲取圖像。

我可能是錯的,但我認爲休息背後的想法是識別每個資源與捆綁一堆圖像並調用資源。只是一個想法...

+0

我同意 - 這樣捆綁東西可能不是很RESTful,但實際上我也在編寫將使用此Web服務的(僅)應用程序,所以我認爲沒關係。 –

+1

關於超時價值的好處,雖然因爲我也在寫客戶端,所以我也可以處理這個問題。 (我可能只會一次請求十幾個)。我認爲發送100張圖片所需的額外流量太多了,因此單獨提取它們聽起來並不合適。 –

相關問題