接口设计概述,自己开发多个项目后的一些总结,应该对大部分人都有用
防抖场景
常见操作
- 给用户会发起请求的按钮操作加防抖或节流, 一般是加节流, 防抖比较慢
- 标志位设置, 如果请求发起了, 就设置标志位为true, 等结果返回了再设置为false. 下次接口发起时,需要判断这个标志位
- react中的实际场景bug
弹窗 发起请求后设置了一个loaing
竞态请求
后续再更
参数校验
post, put请求一定要做 参数校验
背景: 有一个post短信下发接口, 需要一个用户数组参数, 接口是给数组里面的用户发送短信,前端这块漏做了参数校验 ,直接发送了空数组参数[], 然后后端接口的逻辑,是循环给这个数组里面的用户发送短信. 但如果是空数组, 便会给所用的用户发送短信. 导致短信误发全员, 多亏是在灰度阶段测出来的bug, 影响范围尚可挽回
-
前端解决办法, 加参数校验:
Array.isArray(users) && users.length>0 -
后端也要加接口校验, 对前端的任何数据都要有不可信处理
接口如果校验不到位, 还会引起服务雪崩
如上:
如果用户量比较大, 因为接口校验错误,给全员下发短信, 接口操作必然超时, 而前端接口和后端服务都做了超时重新请求, 就会出现服务器 内存 cpu 飙增 ,因为每次请求必然超时,超时后又再次发起重试 服务器干掉都是小事, 怕的就是后台又有弹性服务, 不断去申请资源,不断超时继而又发起重试, 是很可怕的, 当然这属于服务架构的问题了
响应结果反馈
post, put请求一定要有结果反馈, 无论失败成功都要把对应的结果通过message等UI反馈给用户
处理方法, catch + response校验
const data = { username: "example" };
fetch("https://example.com/profile", {
method: "POST", // or 'PUT'
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify(data),
})
.then((response) => response.json())
.then((data) => {
if(data.errorMsg){
return message.error('接口返回错误')
}
console.log("Success:", data);
return message.success('接口返回错误')
})
.catch((error) => {
console.error("Error:", error);
message.error(String(error))
});
也可以用try catch包裹处理
axios
axios请求路径多了一级的问题
// 创建axios实例
const service = axios.create({
baseURL: baseURL, // api的base_url
timeout: 50000,
changeOrigin: true, //跨域
withCredentials: true, // 跨域携带cookie
})
实际请求 url 封装的 API 中调用 service 实例向后台发送请求：
service.get(url, {params})
这个 url 的值，有前缀 “/” 和没有时，请求路径是有差距的。 例如：一个删除接口后台路径是 /myapp/delete 下面两种形式请求路径会不同：
- 以斜杠开始：service.get("/myapp/delete")，这种请情况下，请求路径是正常的，完整路径为 IP:port/myapp/delete。
- 非斜杠开始：service.get("myapp/delete")，此时相对路径是当前路由 path ，最终的请求路径是 IP:port/path/myapp/delete ，无疑会导致 404 异常。
开发过程中漏写了一个杠,就出现这种问题, 还是要细心一点 , 感觉axios这样设计也不是很合理
没有 / 时，请求发送是相对当前页面请求路径的；而有前缀时，相对路径就成了应用根路径了。
参考
blog.csdn.net/wojiushiwo9…
juejin.cn/post/704187…
juejin.cn/post/697953…
axios baseurl 有没有必要写
由于上面的问题, 我有时候也在想baseurl有没有必要写, 但不写肯定不会出错,多写多错.
建议在开发阶段一定要约定好api接口的path形式,比如都以 host/api/xxx 开头
ts对axios的封装
重点
一定要写每个请求的参数和响应类型, 开发起来事半功倍,对每个参数 服务器会不会返回,和返回类型也一定要和后端同事商量好
