ASP.NET中的Web API拆分響應

Question

是否可以按如下方式將響應從WEB API拆分爲塊。

我有一個勝利形式的應用程序，一次可以處理100 KB的數據。

當這個客戶端向我的ASP.NET WEB API請求某些數據時，讓我們假設WEB API響應爲2 MB ......我可以以某種方式緩存這個響應，將它分成100KB塊並返回第一塊到我的應用程序。該響應將包含到下一個塊的鏈接/標記等等？這聽起來很瘋狂嗎？這是可行的嗎？

還有一個問題：當我們談論請求/響應內容的長度（大小）時，這意味着什麼：內容本身不能大於100 KB或帶有標題的內容等......我想要要知道標題是否包含在內容長度中？

例如：如果我的迴應爲99KB，並且標題爲10 KB（109 KB），如果限制爲100KB，會通過嗎？

Answer 1

分頁是一種非常常見的解決方案，適用於Web服務中的大型數據集。例如，Facebook在超過一定數量的行時會對API結果進行分頁。你對本地緩存整個結果的想法是一個很好的優化，但是如果你不確定是否將它作爲你的最終解決方案，你可能不會將它緩存爲第一個實現。

如果沒有緩存，您可以將頁碼和總頁數傳回給您的客戶端，然後可以爲下一組重新撥打特定頁碼的呼叫。這使得客戶端上的循環變得簡單，並且數據訪問層稍微複雜一些，因爲它只會根據頁面參數重新序列化某些行號，但這應該仍然非常簡單。

Web API可以訪問與其他ASP.NET項目類型相同的HttpRuntime.Cache對象，因此應該很容易在您的數據訪問調用中編寫包裝並將較大查詢的結果粘貼到該緩存中。使用令牌作爲緩存中該值的關鍵字，並將密鑰（可能是類的實例）傳遞迴客戶端，並使用當前頁碼。在隨後的調用中，跳過訪問常規持久性方法（DB，文件等），而是訪問HttpRuntime.Cache中的GUID鍵並找到相應的行。與此相關的一個問題是，如果您擁有多個託管服務的Web服務器，因爲HttpRuntime.Cache將僅存在於第一次調用的計算機上，因此除非您的負載均衡器具有IP關聯性，或者您有分佈式緩存層，否則這將更加困難實行。