以 文件重命名 为例:
当完成重命名操作提交会到这个地址 https://pan.baidu.com/api/filemanager
返回如下结果
{
"errno": 0,
"info": [],
"request_id": 88137407060055336,
"taskid": 307843054247316
}
可以联想到在server端建立了一个task, 并返回了taskid让客户端后续取状态来更新ui
客户端轮训服务器的接口 https://pan.baidu.com/share/taskquery
来获取状态, 1秒一次请求, 服务器端返回结果如下: 分几种情况我总结了一下
#进行中的返回值
{
"errno": 0,
"request_id": 88137707954758994,
"task_errno": 0,
"status": "pending"
}
#进行中
{
"errno": 0,
"request_id": 88137707954758994,
"task_errno": 0,
"status": "running"
}
#操作成功的返回值
{
"errno": 0,
"request_id": 88138584419582326,
"task_errno": 0,
"status": "success",
"list": [
{
"from": "/test1/我的照片",
"to": "/test1/我的照片2"
}
],
"total": 1
}
当 status 为success时候, 则轮询结束, 更新UI元素
问题: 直接访问重命名接口不行吗? 为什么要这么设计, 好处是什么?
你已經說的很清楚了啊,還有什麼不懂的?
第一次就是向伺服器發起改名申請。
伺服器就開始任務。
後面的輪詢都是在查詢任務是否完成,完成了前端做對應操作,萬一失敗了,前端還要做回滾操作。
猜一下原因:極端情況下, 操作可能會耗時很久, 無法立即返回. 在操作完成的時候, socket鏈接可能已經斷開, 無法獲取到最終的結果. 設計成任務隊列的方式, 能保證客戶端獲取到最終的結果.
除了上面的一些考慮,可能還有一個很重要的原因,那就是並發壓力。做成異步,能很好解決並發