Apidog 的 APIs 模块提供两种模式，可在界面左下角切换：Design-first Mode 和 Request-first Mode。两种模式提供相似的功能，但界面不同，适用于不同的团队工作流。Design-first Mode 是 Apidog 推荐的模式，适合遵循 API-Design First 方法的团队。在此模式下，团队先制定 API 规范，然后基于 API 规范进行开发和测试。另一方面，Request-first Mode 非常适合初始阶段不定义 API 规范的团队。这些团队通常专注于后端开发，完成代码后再生成 API 规范，以便开始测试和客户端工作。如果你需要调用他人开发的 API，但没有相关文档，也应该使用 Request-first Mode。
Design-First Mode#
在 Design-first Mode 中，编辑 API 规范和发送请求通过不同的标签页进行。用户在 Edit 标签页中修改 API 规范，在 Run 标签页中发送请求。这种分离方式适合遵循 API-Design First 方法的团队，其中 API 架构师和开发者/使用者具有不同的角色。API 架构师定义 API 规范而不发送请求，而开发者则专注于 API 开发和测试，不更改 API 规范。分开的标签页符合这类团队的使用习惯。在 Edit 标签页中，API 架构师可以指定请求示例，这些示例会在 Run 标签页中自动设置为默认参数值。API 开发者/使用者可以在 Run 标签页中进一步修改参数值和请求主体。Request-First Mode#
Request-first Mode 适合不预先指定 API 的团队。后端开发者直接进行 API 开发，并且在开发过程中可能需要调用 API 进行调试。在此模式下，开发者无需一开始就指定 API；相反，他们可以直接输入一个请求，类似于在 Postman 中创建新请求。在这个界面中，开发者可以轻松修改参数类型、名称、值、主体组件等，而无需分别调整 API 规范和请求参数值。调试完成并保存后，请求会自动被解析为端点规范。参数会转换为规范参数和示例值，而请求/响应主体会解析为 schema，主体值会被解释为请求/响应示例。开发者可以根据自身需求进一步完善和增强此端点规范。模式之间的差异#
两种模式之间的关键差异在于，在 Request-first Mode 中，请求主体会被用作端点请求主体示例。相比之下，在 Design-first Mode 中，用户可以在 Run 标签页中输入实际请求主体以及请求主体示例。因此，Run 标签页中的主体部分仅在 Design-first Mode 中可用，在 Request-first Mode 中不可见。另一个区别是，在 Design-first Mode 中，你可以在端点规范级别或运行/端点用例级别添加前置/后置处理器。而在 Request-first Mode 中，由于没有 Run 标签页，所有前置/后置处理器都被视为处于端点规范级别。运行/端点用例级别的前置/后置处理器在 Request-first Mode 中不可见。 