因为之前没有实战过测试平台，所以最近在开发一个接口测试平台练下手，写到接口和用例管理这部分的时候，对数据结构的定义有点犯了难，参考了一些其他平台，有的是把接口和用例干脆都放在一起，有的是先声明接口（接口统一管理）然后把接口发布为用例，放到各个流程中去；我个人感觉后者比较好（PS 如果又大佬有更好的形式，欢迎指教）后面的说明都是针对后者。
我个人的想法是要有两张表
第一张 ob_api 用来存储 api 的基本信息（name、host、headers、method、data、available）
第二张 ob_case，存储关联的 api 及用例的请求数据及期望结果等（api_id、request_data、expected_data、config[接口配置，如前处理、后处理等]）
这样想下来，总感觉缺少了一些地方，但是又不知道具体不合适的点在什么地方
麻烦各位大佬们指教，感谢。
没太看懂楼主的问题核心是什么，最近也在整理接口平台，浅说下我对平台管理的理解。
接口测试分单接口和多接口，用例也如此；单接口用例可以接口为主体进行管理，无需多言；支持多角度实现的多接口用例就没有什么最优解了，核心就是以用例为主体，将涉及接口如何更恰当的加入到用例之中，各类方法的区别无外乎用例的生成方式，用例与接口的关联方式，多接口间的传值方式，执行顺序的控制方式等等。
楼主所说的 “把接口和用例干脆都放在一起” 其实更适用单接口，后者当然更适合多接口测试。页面操作来表述一个多用例的生成可以是如此的：在一个用例主体上依次添加流程接口，两接口间提供前置处理 (参数获取、参数生成等)、后置处理 (提取、断言、判断等) 等功能，还需提供全局参数类功能用于参数流转，除上述核心外还可定制化添加异步执行、异步监控、间隔控制等。在管理结构上可以做项目管理、接口管理 (单接口)、用例管理 (多接口)，报告跟随用例。
接口和用例流程分开比较好。原因如下：
- 实际上，大部分的接口都较为复杂，如果写在用例里面去描述会比较难于编辑
- 接口存储时可以有一些默认参数，因此在用例描述中只需要对一些流程相关参数做修改即可（这个逻辑是双刃剑，因为会导致一些实际实施中的理解成本）
- 接口的描述可以通过 swagger、goreply、代码扫描等方式来做统一的收集，也方便基于接口做 mock 等方案，参考 apipost、yapi 或者类似工具能力。
但实际上，要先考虑你公司的接口是属于哪种类型的接口。我认为接口测试角度来看分为两种类型的测试，1：数据型接口，2：流程型接口
所有的测试方案或者接口平台大多数做的能力是围绕这两种类型的接口测试做更深的组合来实现接口测试平台的价值和意义，所以做接口平台除了考虑接口存储外，还要看这个逻辑。
- 数据型接口更偏重于参数组合和返回结果的多样性，举例：搜索服务等，这类接口之前社区也有很多好的方案，可以研究基于 fuzz 随机测试做接口参数组合，同时定义好规则对返回值做验证。
- 流程型接口更偏重于接口与接口之间的流程参数的转换调用，偏重资源管理，举例：公有云资源服务类 API 接口和大多数据的业务流程接口 这类接口其实测试的是业务逻辑在接口调用过程中的串联组合，所以我自认为现有最合适的方案是 MBT 的方案，毕竟这个方案对整个流程的描述只要正确，生成的用例就绝对可靠，但是说实话市面上比较好用的 MBT 的工具和方案我暂时没有看到过，基于 graphwalker 的描述方案更偏重图，而不在测试流本身的描述。
你这个问题中，我认为倾向于你的接口类型是流程型接口，所以依然结论是建议把接口描述收拢在平台的一个功能中