6.5 KiB
6.5 KiB
接口重复功能分析报告
一、明确的重复接口
1. 财务模块 - 未入职用户列表接口重复
重复的接口：
POST /finance/user-register-detail→UnregisteredUserListPOST /finance/unregistered-user-list→UnregisteredUserList
问题：
- 两个URL路径指向同一个视图类
user-register-detail在注释中标注为"向后兼容，保留旧URL"
建议：
- 保留
unregistered-user-list（更符合RESTful命名规范） - 删除
user-register-detail（旧接口，已标注为兼容）
位置： finance/urls.py 第7行和第6行
二、功能重叠的接口
2. 获取案件列表接口（开票相关）
接口1： GetCaseListForInvoice
- 路径：
POST /finance/case-list-for-invoice - 功能：获取所有案件列表（仅从ProjectRegistration获取）
- 返回：案件ID、合同号、负责人、项目类型、立项时间
接口2： SearchCaseByContractNo
- 路径：
POST /finance/search-case-by-contract-no - 功能：通过合同号搜索案件（从Case和ProjectRegistration搜索）
- 返回：更详细的案件信息，包括客户名称、相对方等
分析：
GetCaseListForInvoice功能较简单，只返回所有案件SearchCaseByContractNo功能更强大，支持搜索且返回信息更完整- 两者功能有重叠，但使用场景不同
建议：
- 可以合并：在
GetCaseListForInvoice中添加搜索参数，使其支持按合同号搜索 - 或者保留两个接口，但明确使用场景：
GetCaseListForInvoice：用于下拉选择（返回所有案件）SearchCaseByContractNo：用于搜索（支持模糊搜索）
3. 开票申请接口
接口1： issueAnInvoice
- 路径：
POST /finance/issue-invoice - 功能：财务开票申请
- 特点：
- 支持通过case_id选择案件
- 需要审批流程（state="审核中"）
- 必须提供token验证
接口2： AddInvoice
- 路径：
POST /finance/add-invoice - 功能：增开票申请
- 特点：
- 支持通过case_id或project_id选择案件
- 直接抄送财务（state="待财务处理"）
- 不需要审批流程
分析：
- 两个接口功能相似，都是创建开票申请
- 主要区别在于审批流程不同
AddInvoice功能更完善（支持project_id，直接抄送财务）
建议：
- 可以合并为一个接口，通过参数控制是否需要审批
- 或者保留两个接口，但明确使用场景：
issueAnInvoice：普通开票（需要审批）AddInvoice：增开票（直接抄送财务）
4. 案件标签设置接口
接口1： EditCase
- 路径：
POST /business/editCase - 功能：编辑案件信息（包括设置标签）
- 特点：
- 可以编辑案件的各种信息（时间、文件、金额等）
- 支持通过
tag_ids参数设置标签 - 需要提供案件ID和其他可选字段
接口2： SetCaseTags
- 路径：
POST /business/set-case-tags - 功能：专门用于设置案件标签
- 特点：
- 只设置标签，不修改其他信息
- 更简洁，只需提供case_id和tag_ids
- 有更详细的标签验证和错误提示
分析：
EditCase功能更全面，但设置标签只是其功能之一SetCaseTags更专注，专门用于标签管理- 两者功能有重叠，但使用场景不同
建议：
- 保留两个接口，但明确使用场景：
EditCase：编辑案件信息时顺便设置标签SetCaseTags：专门用于批量设置或只设置标签的场景
三、命名容易混淆的接口
5. 日程相关接口命名
接口1： DeleteSchedule（但URL是 scheduledetail）
- 路径：
POST /business/scheduledetail - 功能：删除日程
- 问题：URL名称
scheduledetail暗示是详情接口，但实际是删除功能
接口2： ScheduleDetail
- 路径：
POST /business/ScheduleDetail - 功能：日程展示（列表）
建议：
- 将
scheduledetail改为delete-schedule或schedule-delete - 或者将
DeleteSchedule类名改为更明确的名称
6. 律师文件相关接口命名
接口1： LawyersdocumentsDetail
- 路径：
POST /business/lawdisplay - 功能：律师文件列表展示
接口2： LwaDetail
- 路径：
POST /business/LwaDetail - 功能：删除律师文件（软删除）
- 问题：类名和URL都暗示是详情接口，但实际是删除功能
建议：
- 将
LwaDetail改为DeleteLawyerFile或LawyerFileDelete - 将URL
LwaDetail改为delete-lawyer-file
四、功能相似但用途不同的接口
7. 下拉列表接口
接口1： ProjectDropdownList
- 路径：
POST /business/project-dropdown-list - 功能：获取立项登记下拉列表
接口2： CaseDropdownList
- 路径：
POST /business/case-dropdown-list - 功能：获取案件下拉列表
分析：
- 两个接口功能相似，都是获取下拉列表
- 但数据源不同（ProjectRegistration vs Case）
- 属于正常的功能分离，不是重复
建议：
- 保持现状，这是合理的接口设计
五、总结和建议
需要立即处理的重复接口：
- 删除旧接口：
user-register-detail（finance/urls.py 第7行）- 已有新接口
unregistered-user-list替代
- 已有新接口
建议优化的接口：
-
合并或明确分工：
GetCaseListForInvoice和SearchCaseByContractNo：建议合并或明确使用场景issueAnInvoice和AddInvoice：建议合并或明确使用场景
-
重命名接口：
scheduledetail→delete-schedule或schedule-deleteLwaDetail→delete-lawyer-file
可以保留的接口：
- 功能重叠但使用场景不同：
EditCase和SetCaseTags：保留两个接口，但明确使用场景
六、接口统计
- business模块： 约60个接口
- finance模块： 约30个接口
- User模块： 约20个接口
- 总计： 约110个接口
发现的重复/问题接口： 6组
七、建议的优化方案
方案1：删除明确的重复接口
- 删除
user-register-detail路由
方案2：统一接口命名规范
- 使用RESTful风格：
resource-action格式 - 例如：
delete-schedule、delete-lawyer-file
方案3：合并功能相似的接口
- 在
GetCaseListForInvoice中添加搜索参数 - 在
issueAnInvoice中添加参数控制审批流程
方案4：完善接口文档
- 明确每个接口的使用场景
- 标注接口的优先级（推荐使用/兼容保留）