
【免费下载链接】ApiManager接口文档管理工具项目地址https://gitcode.com/gh_mirrors/api/ApiManager点击查看免费下载ApiManager 是一款基于 Go Gin 编写的在线 API 文档管理工具帮助中小团队快速完成接口文档的编写、维护与存档。它的数据库设计非常值得新手学习整个系统只用了4 张核心表却通过一个「接口参数 JSON 存储」的巧妙方案把任意数量的请求参数装进了单个字段里。这篇文章带你逐表拆解 db.sql 中的表结构看懂这套轻量级数据库设计背后的取舍。4张核心表一览极简但不简陋打开数据库初始化脚本 db.sql你会看到完整的表结构只有 4 张表名中文注释作用api接口明细表 核心表存放每个接口的地址、参数、返回值cate接口分类表按业务模块给接口分组user用户表账号、角色超管/管理员/游客auth权限表普通管理员与接口分类的授权关系整个库统一使用utf8字符集表结构定义在 db.sql配套的 Go 数据模型分别位于 app/models/api.go、app/models/cate.go 和 app/models/user.go。api 表一张表承载接口的全部信息api表是 ApiManager 数据库设计的灵魂一行记录就是一个接口。关键字段如下字段类型设计意图aidint所属分类 id关联cate表numvarchar接口编号便于检索如001url/typevarchar / char请求地址与请求方式GET/POSTparametertext⭐所有请求参数以 JSON 格式存放下文详解parameter_textlongtextbody 请求体等文本参数re/memolongtext返回值示例与备注lastuid/lasttimeint最后修改人与时间操作可追溯ordint排序值值越大越靠前isdeltinyint软删除标记0 正常 / 1 删除几个值得注意的实战细节 软删除Delete()只是执行update api set isdel1见 app/models/api.go数据不落地删除随时可恢复这也是所有查询都带WHERE isdel0的原因。操作留痕列表查询时会LEFT JOIN user取login_name界面上Last modify: root 2021-03-07正是来自lastuidlasttime两个字段。一条 SQL 批量排序拖拽排序时通过CASE WHEN一条语句更新全部ord值避免逐行 UPDATEapp/models/api.go。接口参数 JSON 存储方案单字段替代参数明细表这是全文最值得学习的部分。很多系统会为参数单独建一张明细表一行一个参数但 ApiManager 选择了用 JSON 把参数数组序列化后存进parameter单字段。写入流程后端前端提交 5 组平行数组控制器用json.Marshal一次序列化后落库app/controllers/api.gopars : params{ ParamName: apiRequest.ParamName, // 参数名 ParamType: apiRequest.ParamType, // 参数类型 ParamCate: apiRequest.ParamCate, // 参数分类 ParamDefault: apiRequest.ParamDefault,// 默认值 ParamDes: apiRequest.ParamDes, // 参数描述 } jsonBytes, _ : json.Marshal(pars)库里实际存的样子以用户注册接口为例{ param_name: [login_name, password, sms_code], param_type: [string, string, string], param_cate: [query, query, query], param_default: [, , ], param_des: [用户登录名, 用户密码, 短信验证码] }5 个数组按下标一一对应第 i 个元素拼起来就是参数表的一行。读出流程前端页面加载时JSON.parse还原数组逐行渲染成 Request Parameters 表格app/static/common.js。编辑时走同一个函数getApiParamsViewForEdit直接还原成表单输入框。这种接口参数 JSON 存储方案的好处很明显✅表结构稳定接口有 3 个还是 30 个参数都不影响表结构无需改表✅读写都只碰一行新增/复制/编辑接口各只需一条 SQLDuplicateApi甚至能直接INSERT...SELECT整行克隆app/models/api.go✅对文档工具足够参数不需要被 SQL 条件检索JSON 里的灵活性正好用上。代价是无法用 SQL 直接查询某个参数属于哪个接口——但对于一个面向团队的文档系统这是完全可以接受的取舍。用 JSON 换灵活性是轻量工具数据库设计中非常经典的手法。user 与 auth 表三级角色的权限设计user表用一个role字段区分三级角色1超级管理员、2管理员、3游客login_name上有唯一索引保证账号不重复。密码字段login_pwd为 32 位定长存放的是 MD5 摘要登录逻辑见 app/models/user.go。auth表只有两个字段uid用户aid接口分类。它解决的是普通管理员的细粒度授权——超级管理员天然拥有全部权限而管理员登录后只读取auth表中属于自己的aid列表就能限定其只能看到被授权的那几个分类。快速上手如何体验 ApiManager 的数据库结构想亲手验证这套表结构三步即可获取源码git clone https://gitcode.com/gh_mirrors/api/ApiManager建库并导入表结构在 MySQL 中创建api_manager数据库导入 db.sql4 张表即刻就绪配置连接后启动修改 config/config.ini 中的数据库连接信息执行./run.sh start浏览器访问http://your_host:8000默认账号root/ 密码123456。登录后新建一个分类和接口再用客户端查询api表你就能亲眼看到parameter字段里那份整齐的参数 JSON。小结ApiManager 用 4 张表撑起了一套完整的接口文档管理系统三个设计点尤其值得借鉴api单表承载全量接口信息配合isdel软删除与lastuid/lasttime留痕接口参数 JSON 存储5 组平行数组序列化为 JSON 存入单字段结构稳定、读写高效roleauth组合授权粗粒度角色与细粒度分类权限各司其职。这套够用就好的数据库设计既是团队文档工具的合适形态也很适合作为学习 Gin 框架时研究数据模型的入门样本。赞分享【免费下载链接】ApiManager接口文档管理工具项目地址https://gitcode.com/gh_mirrors/api/ApiManager点击查看免费下载相关推荐揭秘lakeFS核心技术基于KV存储的元数据架构设计全解析揭秘lakeFS核心技术基于KV存储的元数据架构设计全解析 lakeFS作为一个专为云原生数据湖设计的分布式文件系统其核心优势在于基于KV存储的元数据架构设数据湖后端对象存储数据工程版本控制龙果支付系统roncoo-pay数据库设计25张核心表结构完全解析龙果支付系统roncoo pay数据库设计25张核心表结构完全解析 龙果支付系统roncoo pay是国内首款开源的互联网支付系统拥有独立的账户体系、用后端金融科技如何优化移动端H5首屏加载VasSonic数据库设计与SonicDBHelper缓存方案全解析如何优化移动端H5首屏加载VasSonic数据库设计与SonicDBHelper缓存方案全解析 VasSonic是腾讯VAS团队开发的轻量级高性能Hybrid移动开发前端后端上一篇Alumnium 进阶难题清单多标签页、Shadow DOM、文件上传、拖拽滑块9 类复杂场景逐一破解下一篇SmolLM2-135M-Instruct_rai_1.8.0_hybrid 性能实测135M 参数 8K 上下文迷你 LLM 能走多远创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考