以 文件重命名 为例:
当完成重命名操作提交会到这个地址 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元素
问题: 直接访问重命名接口不行吗? 为什么要这么设计, 好处是什么?
그 밖에 이해가 안 되는 부분이 있나요?
첫 번째는 서버에 대한 이름 변경 신청을 시작하는 것입니다.
서버가 작업을 시작합니다.
이후 폴링은 작업이 완료되었는지 확인하는 것으로, 완료 후 프런트엔드에서 해당 작업을 수행하며, 실패할 경우 롤백 작업도 수행합니다.
이유 추측하기: 극단적인 경우 작업 시간이 오래 걸리고 즉시 반환되지 않을 수 있습니다. 작업이 완료되면 소켓 링크가 끊어져 최종 결과를 얻을 수 없는 경우가 있습니다. , 클라이언트가 최종 결과를 얻는지 확인할 수 있습니다.
위 고려 사항 외에도 또 다른 매우 중요한 이유가 있을 수 있는데, 바로 동시성 압박입니다. 비동기식으로 만들어 동시성을 해결할 수 있습니다