优化Camunda API：构建Zeebe REST API

使用不同协议和架构的多个API可能会带来一定的挑战。这也是为什么我们决定精简Camunda产品的API，并最终为Zeebe、Operate、Tasklist、Optimize和Identity组件提供统一的REST API。

为什么选择构建Zeebe REST API？

虽然Zeebe当前的gRPC API在微服务架构中具有诸多优势，例如支持双向数据流和高性能用例，但许多开发者认为gRPC的学习曲线较为陡峭。此外，使用gRPC可能会增加组织内部安装和配置Camunda的复杂性。

为了降低学习成本并简化安装流程，我们正在为Zeebe构建一个全面的REST API。这是统一Camunda 8 API的第一步。新的REST API将包含以下三类端点：

Zeebe将负责管理用户任务的状态，并引入一种新的用户任务类型：Zeebe用户任务。为此，我们将通过专门的REST端点来支持用户任务管理。这一更新将确保从任务列表API到Zeebe API的迁移顺利进行，同时继续支持旧的任务类型。

我们将逐步将现有的gRPC端点迁移到REST端点，并根据端点的重要性和用例支持情况进行优先级排序。这种分阶段的迁移策略能够确保系统的平稳过渡，最大限度地减少对开发者的影响。

新的REST API将提供额外的GET端点，用于直接从Zeebe中检索实时流程实体状态（如用户任务、流程实例和变量等）。这些GET方法对于开发者实现运行时交互至关重要，能够帮助他们基于实体的当前状态决定下一步操作。

我们最初选择gRPC是因为它在低延迟和高吞吐量用例中表现优异。因此，对于这些高性能场景，我们将继续保留专门的gRPC端点。

在迁移过程中，我们将提供详细的指导，帮助开发者判断何时应该使用REST API或gRPC API。一旦除“Job-Push”以外的所有gRPC端点都迁移到Zeebe REST API，我们将在两个小版本后弃用并删除不再需要的gRPC端点。

对于使用支持客户端或SDK的开发者，迁移路径将非常简单。客户端将支持REST API迁移，您只需确保网络已为REST API开放正确的端口。我们的目标是最大限度地减少迁移工作量，提供无缝的过渡体验。

在未来版本中，gRPC将在Zeebe网关中默认处于非活动状态。不过，当您的用例需要减少作业激活延迟时，仍可以通过gRPC启用作业流。

为了提升用户体验并简化集成流程，我们推出了官方支持的SDK，并更新了Zeebe客户端以支持多种编程语言。

NodeJS：即将正式支持，旨在统一不同API之间的交互，为Camunda 8提供无缝集成体验。
Spring Zeebe SDK和Zeebe Java客户端：将同时支持gRPC API和REST API，帮助开发者轻松实现协议迁移并简化客户端应用程序的开发。

此外，我们还将提供以下工具以优化开发体验：

在Zeebe REST API完成后，Go和zbctl客户端将被转移到Camunda社区中心。这意味着这些客户端将不再由Camunda官方支持，Camunda Engineering将停止为其修复错误和开发新功能，Camunda Support也将不再提供支持。

社区用户可以自由分叉和扩展这些客户端。通过REST API，与Zeebe引擎的交互将变得更加简单。您可以使用OpenAPI定义、Postman集合或cURL快速上手，并在代码中实现API调用。同时，我们建议您尝试新的客户端和SDK，以获得更好的开发体验。

我们将逐步推出API更改，从用户任务端点开始。请关注即将发布的博客文章，了解如何在Zeebe中管理用户任务。如果您有任何疑问，欢迎访问Camunda论坛进行讨论。

通过引入Zeebe REST API，我们旨在降低开发者的学习成本，简化安装和配置流程，并为高性能用例提供灵活支持。新的客户端和SDK将进一步提升开发体验，而社区的参与将为Zeebe生态系统注入更多活力。未来，Camunda将继续致力于为开发者提供更高效、更便捷的工具和解决方案。

原文链接: https://camunda.com/blog/2024/03/streamlining-camunda-apis-zeebe-rest-api/