从SQL查询迁移到API请求时如何组织Python项目结构？

你提出的requests/目录结构是可行的，但还有几个更贴合语义、扩展性更好的命名方案可以参考：

可选的目录命名方案 #

• api/：最通用的命名，明确表示这是与外部API交互的模块，不管是GET/POST请求都适用，比requests/更宽泛，后续新增不同类型的API调用时更灵活
• client/：如果这些请求是针对特定服务端的客户端封装，这个命名更能体现模块的作用，比如可以进一步拆分为api/client/或者直接用client/存放所有服务端交互逻辑
• endpoints/：直接对应你提到的替代DB的endpoints，语义完全匹配，一眼就能看出目录里的代码是处理各个端点请求的

关于你提出的requests/结构的说明 #

这个命名是可以用的，但要注意：

• 每个requestX.py里最好封装完整的请求逻辑，包括参数处理、请求发送、响应解析、错误处理，而不是只放简单的请求调用
• 如果后续有多个不同服务的端点，建议在requests/下再按服务细分，比如requests/user_service/、requests/order_service/，避免文件杂乱

结构示例（以api/为例） #

project_root/
├── api/
│   ├── user_api.py
│   ├── order_api.py
│   └── ...
├── main.py
└── ...

内容的提问来源于stack exchange，提问作者error404