Box api v2「文件夾」響應太有限

我正在使用Box v2.0 api將Box整合到iOS應用程序中。Box api v2「文件夾」響應太有限

我遇到的第一個問題是，對API調用「文件夾」API請求的響應太有限。什麼API返回當前爲每個文件夾「項」是一樣的東西：

"entries" : 
[ 
    { 
     "sequence_id": "0", 
     "type": "file", 
     "id": "2631999573", 
     "name":"IMG_1312.JPG" 
    }, 
    { 
     "type":"folder", 
     "id":"2305623799", 
     "sequence_id":"1", 
     "name":"a child folder" 
    } 
]

這意味着，一個孩子進入檢索基本的元數據（大小，修改日期等），我要爲每筆一個REST請求 item。這顯然非常低效。

有沒有辦法在「folders /」響應中獲得更豐富的元數據？它可以通過在請求中提供合適的查詢來過濾。例如

GET /folders/980980989?fields=name,id,type,size,modified_at

來源

2012-07-31 John

喬治：Box.com使用stackoverflow作爲他們的開發者「論壇」。我要求澄清有關他們的「文件夾」v2 REST API方法。 – John 2012-08-09 10:00:14

-1

是的，你必須查詢各個子項以獲得其在V2.There信息是沒有其他辦法

來源

2012-07-31 18:38:41 auny

@auny

這是非常，非常低效的。例如，我們的iOS應用程序是一個文件查看器 - 當用戶導航到Box目錄時，他們會看到該目錄中的所有文件（在表格視圖中）的列表。該視圖由存儲基本文件元數據（名稱，大小，修改日期等）的本地「模型」進行備份。每個文件顯示它的名稱，大小和修改日期。

隨着V2 API箱期待我們做出一個單獨的REST API調用每個文件的目錄（可能是數百個，1000個或更多）簡單地確定大小和修改日期。這對移動應用程序而言效率很低。

不要忘記，通常與移動它的延遲（不帶寬），影響性能。好吧，帶寬也可能不是很好，但100個REST呼叫的延遲將是一個主要問題。

1 REST調用來確定目錄的基本元數據，即使在響應中需要多幾KB，也遠遠優於單獨REST調用的100個。

文件夾響應已經爲每個目錄條目提供了一些元數據，即使這些字段只能通過請求獲得，也不會很難包含其他字段。

瘋了。

來源

2012-08-01 12:12:09 John

Box api v2「文件夾」響應太有限

回答

相關問題