围绕自动生成的客户端绑定使用自定义客户端代码

Question

(请让我知道这个问题是否属于不同的stackexchage站点)

我有一个用例，其中我的服务的客户端必须调用服务中公开的一些API。所使用的API规范模型允许自动生成不同语言的客户端绑定。

我需要围绕一些API提供增强的功能，并且自定义代码位于对API的调用周围。我不希望每个客户端都自己编写这些代码，而是将其作为自动生成的客户端库的包装器来提供。我知道需要对支持的不同语言执行此操作(在我的例子中，列表为2-3 )。

总的来说，这是一个好的选择吗？还有没有别的选择？

如果需要更多细节，请让我知道。

Answer 1

从某种API定义(如OpenAPI)生成客户端并将其与其他代码一起发布是一种非常常见的模式，我在过去使用和创建过这样的客户端。对于API的使用者来说，这有一些明显的优势:他不必生成客户端(取决于所使用的技术有时是痛苦的)，他从提供者(和其他人)所做的维护中受益，并使用官方方式与API进行交互。

在这样的客户端中，有三个主要的包，它们应该相互分离和独立：

• 生成的client
• 代码，它简化了生成的client
• 其他代码(即抽象或简化公共交互、提供客户端所需的域逻辑等的实用程序)的使用。

如果这些是分开的，消费者很容易选择他想要使用的部分。

主要缺点是您必须为您的API实现和维护多个客户端。根据API的大小、支持的平台和使用客户端的环境，这可能是一项非常复杂的任务。还要记住，提供一个像样的客户端库需要对目标平台和环境有很好的了解。否则，您的客户端库可能不会被其他开发人员接受。

通常情况下，生成的代码并不是那么“自然”和“漂亮”。例如，生成的标识符可能不遵循平台的约定，或者需要使用复杂的构造(如工厂)来创建简单的对象。通常可以对生成器进行调整，但这会增加所需的工作量。

所有这些努力常常加在一起，因此即使是大型API提供商也很难为许多平台提供良好的客户端库。

有两种选择：

• 仅提供Definition
• Handcraft a client

的接口

第一种选择让消费者可以自由地选择他想要使用API的方式。但是，如果有一个好的API定义(很难编写)，那么这样做就相对容易了。在这种情况下，不可能向客户端提供一些额外的代码。但通常情况下，您应该瞄准愚蠢的客户端，避免客户端执行业务逻辑。

如果你的目标是在有限的平台上为消费者提供尽可能好的体验，那么手工制作的客户端是最合适的。此外，您还可以实现所有其他类型的东西。但即使对于一个单一的平台，这也可能是一项巨大的努力。