第 45 章 API 组件框架简介

对于带有少量选项的组件，实施组件的标准方法(第 38 章 实施组件)非常有效。然而，它开始会变得有问题，就是当您需要实施带有大量选项的组件时。当涉及企业级组件时，此问题会变得显著，这需要您包装包含 数百个 操作的 API。此类组件需要大量努力来创建和维护。

API 组件框架被精确开发，以应对实施此类组件的问题。

基于 Java API 实施 Camel 组件的经验表明，很多工作是日常工作和机械。它包括采用特定的 Java 方法，将其映射到特定的 URI 语法，并允许用户通过 URI 选项设置方法参数。这种类型的工作是自动化和代码生成的明显候选者。

自动化实施 Java API 的第一步是设计将 API 方法映射到 URI 的标准方法。为此，我们需要定义一个通用 URI 格式，可用于嵌套 任何 Java API。因此，API 组件框架为端点 URI 定义以下语法：

scheme://endpoint-prefix/endpoint?Option1=Value1&...&OptionN=ValueN

其中 scheme 是组件定义的默认 URI 方案； endpoint-prefix 是简短的 API 名称，它映射到来自嵌套的 Java API 的类或接口之一； 端点 映射到方法名称；以及 URI 选项映射到方法参数名称。

如果 API 仅包含单个 Java 类，则 URI 的 endpoint-prefix 部分将变为冗余，您可以使用以下更短格式指定 URI：

scheme://endpoint?Option1=Value1&...&OptionN=ValueN

要将 Java 方法调用映射到 URI 语法，很明显需要某种形式的反映机制。但是，标准的 Java 反映 API 遭受显著限制：它不会保留方法参数名称。这是一个问题，因为我们需要方法参数名称来生成有意义的 URI 选项名称。解决方案是以替代格式提供元数据：作为 Javadoc 或方法签名文件。

javadoc 是 API 组件框架的理想元数据形式，因为它保留了完整的方法签名，包括方法参数名称。也可以轻松生成（特别是使用 maven-javadoc-plugin），并且在很多情况下，第三方库已经提供了。

如果出于某种原因 Javadoc 不可用或不适合，API 组件框架还支持替代的元数据来源：方法签名文件。签名文件是一个简单的文本文件，它由 Java 方法签名列表组成。通过从 Java 代码复制和粘贴（轻松编辑生成的文件）来手动创建这些文件相对容易。

从组件开发人员的角度来看，API 组件框架由多个不同的元素组成，如下所示：