在 java 中，会定义一个接口交由下层实现，上层通过接口类型在 spring 容器中找出所有 bean 实现并依次遍历调用。
而在飞布中，会将定义的 api 动态注册到路由中，同时定义的钩子也会在开启的状态下进行注册，最终呈现的结果，界面定义并控制钩子的调用
二、我们的期望：启发与引导
为了应对需求的频繁变更，在有一定技术积累和追求的前提下，会尽量将与业务无关性的逻辑抽象出来，实现前人种树后人乘凉。但这并不是一件容易做的事，对业务的整体把控、对设计模式的了解和实践抽象的手段缺一不可。虽然会在一开始就立志于做到低耦合，但是对代码的思考不是一蹴而就的。我们希望 fireboom 不仅是提升开发效率的工具，同时也能帮助开发者构建一种新的认知，一种基于声明 API 的开发方式。
同时，我们还期待 fireboom 的抽象能给乐于思考的开发者带来一些启发与引导。比如，原先在开发 API 时，一般的步骤是首先部署 API 网关，然后将 API 添加到网关中并保护它们，而 API 的版本管理通常是通过在 URL 上添加版本标识来实现，诸如”/v1”, “/v2”等。但是，软件开发围绕着 git 进行，为何不能把 API 也交由 git 进行版本管理？当然，做到这一点并不容易，需要将管理身份验证、授权、安全等功能抽象出来，但 fireboom 抽象了网关，允许通过编写一部分的代码来配置和管理 API ，能够以声明性的方式管理 API 。
三、声明性 API 依赖性-思考 API 的新方法 多年来，我们一直在使用 NPM 、Maven 或 Go 模块等软件包管理器来管理我们的“代码依赖项”。然而，在管理 API 方面，我们仍然处于石器时代。有时，我们会安装 SDK 来使用 API ，但通常情况下，我们只是使用 API 的 HTTP 请求，API 调用遍布在整个代码库中。最终结果是，我们的代码可能是干净的，但我们完全不知道我们依赖什么 API 。
而单一的统一 API 会是改进架构的好方法。前端直接依赖于多个 API 和服务。在最坏的情况下，N 个 API 可能依赖于 M 服务，而 M 服务依赖于 N 个 API 。每个单独的连接都可以由 API 网关管理，但连接的组成不是。为了解决这一问题，我们可以将多个 API 组合成一个捆绑包，然后将其通过单个接口提供给前端应用程序。在这种情况下，API 依赖项已明确定义，并且可以为整个组合配置身份验证、授权、缓存等策略。这可能并不明显，但能够同时为 RestApi 、Kafka 和 PostgreSQL 的组合定义安全策略，使开发人员的生活变得轻松得多。
如今，内部（微）服务和外部第三方 API 数量相当庞大，几乎每个单独的问题，都有一个对应的 API 可以解决。fireboom 通过统一 API ，可以使这些部分很好地结合在一起，使架构更加简洁，API 管理更加便利。
同时，单一的统一 API 也是促进团队协作的好方法。一般来说，有三类因素常常阻碍团队协作的效率:一是开发者之间存在能力差异；二是对抽象的方式难以一致；三，也是最重要的，实现抽象逻辑的意愿不一，这些都可能造成团队内部各色各样的问题。而统一的 API 会是一种不错的解决方式。
四、案例
1. 简单的数据模型字段变更 1. 通常的低代码平台再次生成代码时会覆盖自定义的业务逻辑，变更后的字段查找替换也是件麻烦的事。 2. Fireboom 因为是动态注册 API ，生成的代码不会对定义的逻辑造成干扰，同时类型安全也极大的方便了变更字段的查找
2. 前后端协作 1. 通常情况下，API 变更同时需要更新对应的 swagger 注释或注解，前端需要等待后端部署后才能看到新的接口文档 2. fireboom 在变更 api 中逻辑后，界面点击保存上线后即发布 API 并同时更新接口文档，即时省心