資源上傳服務支持多種上傳模式和響應模式。開發者可以根據需要組合使用兩種模式，以最快的速度完成期望的業務流程。 ## 上傳類型 開發者可以選擇以下幾種上傳類型來完成一個文件的上傳過程。 1. 表單上傳 該模型在一個單一的HTTP POST請求中完成一個文件的上傳，比較適合于簡單的應用場景和尺寸較小的文件。 關于表單上傳的使用細節，請參見[表單上傳](http://developer.qiniu.com/docs/v6/api/overview/up/form-upload.html)。 2. 分片上傳 顧名思義，分片上傳是將一個文件分為多個尺寸相同的小數據塊，每個小數據塊以一個獨立的HTTP請求分別上傳。所有小數據塊都上傳完成后，再發送一個請求在服務端將這些小數據塊組織回一個邏輯資源，以完成這個上傳過程。 相比簡單上傳而言，切片上傳機制可以提供以下幾個明顯的好處： 1. 適合于尺寸較大的文件傳輸，通過切片來避免單個HTTP數據量過大而導致連接超時； 2. 在網絡條件較差的環境下，較小的尺寸可以有較高的上傳成功率，從而避免無休止的失敗重試； 3. 超過4MB的大文件可以劃分為多個4MB大小的數據塊并發上傳； 4. 支持斷點續傳； 相比簡單上傳，分片上傳需要多次HTTP請求才能完成上傳過程，因此必然會有額外的成本開銷。另外代碼的復雜度也會有明顯增加，因此選擇是否使用分片上傳時應謹慎評估使用該方法的必要性。 分片上傳的相關細節請參見[分片上傳](chunked-upload)。 ## 響應類型 從結果響應的角度，上傳模型支持幾種不同的響應方式和通知目標。 1. 簡單反饋 簡單反饋是指最直接的HTTP響應方式。客戶端發起一次上傳請求，然后等待服務端返回結果。服務端在處理完該次上傳請求后，將處理結果以HTTP響應的方式反饋給客戶端。 簡單反饋的相關細節請參見[簡單反饋](http://developer.qiniu.com/docs/v6/api/overview/up/response/simple-response.html)。 2. 303重定向 303重定向通常在瀏覽器上傳的場景中使用。瀏覽器中的網頁可以在發起上傳請求的同時通知服務器，一旦上傳成功，服務器應該返回HTTP 303狀態碼并帶上一個重定向URL。瀏覽器在收到服務器返回的這個重定向指令后，將當前頁面跳轉到對應的重定向URL。 303重定向的使用細節請參見[303重定向](http://developer.qiniu.com/docs/v6/api/overview/up/response/redirect.html)。 3. 回調通知 回調通知是指客戶端在上傳時指定服務端在處理完上傳請求后，應該通知某個特定服務器，在該服務器確認接收了該回調后才將所有結果返回給客戶端。 因為加入了回調請求和響應的過程，相比簡單上傳，使用回調通知機制一般會導致客戶端花費更多的等待時間。 回調通知的使用細節請參見[回調通知](http://developer.qiniu.com/docs/v6/api/overview/up/response/callback.html)。 4. 異步數據處理 客戶端可以要求服務端在資源上傳完成后以異步的方式開始處理剛剛上傳的資源。要達到這個目標，可以在上傳時指定相應的數據處理操作和參數。所有七牛云存儲已經支持的數據處理服務均可以作為該請求的設置目標。 異步數據處理的使用細節請參見[異步數據處理](http://developer.qiniu.com/docs/v6/api/overview/up/response/persistent-op.html)。 ## 授權機制 資源的上傳授權機制采用[上傳憑證](http://developer.qiniu.com/docs/v6/api/overview/security.html#upload-token)。 ## 常見問題 [上傳成功后返回的JSON會導致IE彈出下載框？](http://kb.qiniu.com/5487y5np)