Use well-known REST API to interact with Zeebe and build process applications faster.
User Problem 🤦
The introduction of the Zeebe REST API aims to simplify installation processes and improve communication with Camunda 8. We aim to address the following customer challenges:
Ease the installation and configuration
Many customers currently face difficulties installing the platform due to challenges in operating gRPC in their network. The limited widespread presence of the HTTP/2 protocol among our customers, either due to lack of preparation, protocol blocking, or other operational issues, contributes to this challenge. The complexity of changing regular procedures or application layer protocols demands considerable time and effort from our customers.
To avoid customer problems regarding Zeebe API usage (Rest and gRPC) we will provide parity of support for custom middleware.
Simplified adoption
With the current API, customers often question, “Why do we need to use gRPC?”. This perceived friction in adoption arises from the unfamiliarity of developers with this type of API, necessitating additional time for education, experimentation, and understanding. Furthermore, consulting and support teams need to invest extra effort in assisting customers with their initial steps.
Unified developer experience
The inconsistency in API types within Camunda 8, where all APIs (except Zeebe) are in REST API, creates an additional challenge for our customers' development teams. The Zeebe gRPC API requires different handling, involving different tools and schemas. The use of gRPC for web applications in frontend applications is not possible without an additional proxy, leading to increased complexities in installation and implementation efforts.
In summary, for customers with no high-performance use cases, the gRPC API introduces additional friction in the adoption of our product. This, in turn, extends the time to value as technical teams invest more time in deploying, configuring, and integrating Camunda into their systems.
Release notes
We're thrilled to announce the integration of Zeebe endpoints into Camunda 8 REST API, aimed at enhancing your experience in building process applications. This will ease the installation and onboarding to Camunda 8 as gRPC won't be required anymore. With the introduction of Zeebe endpoints in REST API, we're eliminating the need for gRPC, reducing friction in adoption. Developers can now seamlessly transition from gRPC to REST with the assurance of having the same endpoints, thereby saving time and effort. Use officially supported Camunda SDKs to have an easy migration journey.
User Stories 🧑🚀
As a Developer, I can use Zeebe endpoints in Camunda 8 API to build my process application
As a Developer, I can migrate from gRPC to REST and have the same endpoints
As a Developer, I can use Java and Spring SDK to build my application and easily migrate to REST
As a Developer, I can read the documentation about REST API and how to migrate from gRPC
As a Developer, I understand the long-term strategy for Camunda API and that REST will be the long-term supported
As a Developer, I understand when to use gRPC for my high-performance use cases
As a Developer, I can use Interceptor API to build custom middleware
Implementation 👷
This product iteration contains increments 4-7 from this document.
Value Proposition Statement 🚀
Use well-known REST API to interact with Zeebe and build process applications faster.
User Problem 🤦
The introduction of the Zeebe REST API aims to simplify installation processes and improve communication with Camunda 8. We aim to address the following customer challenges:
Ease the installation and configuration
Many customers currently face difficulties installing the platform due to challenges in operating gRPC in their network. The limited widespread presence of the HTTP/2 protocol among our customers, either due to lack of preparation, protocol blocking, or other operational issues, contributes to this challenge. The complexity of changing regular procedures or application layer protocols demands considerable time and effort from our customers.
To avoid customer problems regarding Zeebe API usage (Rest and gRPC) we will provide parity of support for custom middleware.
Simplified adoption
With the current API, customers often question, “Why do we need to use gRPC?”. This perceived friction in adoption arises from the unfamiliarity of developers with this type of API, necessitating additional time for education, experimentation, and understanding. Furthermore, consulting and support teams need to invest extra effort in assisting customers with their initial steps.
Unified developer experience
The inconsistency in API types within Camunda 8, where all APIs (except Zeebe) are in REST API, creates an additional challenge for our customers' development teams. The Zeebe gRPC API requires different handling, involving different tools and schemas. The use of gRPC for web applications in frontend applications is not possible without an additional proxy, leading to increased complexities in installation and implementation efforts.
In summary, for customers with no high-performance use cases, the gRPC API introduces additional friction in the adoption of our product. This, in turn, extends the time to value as technical teams invest more time in deploying, configuring, and integrating Camunda into their systems.
Release notes
We're thrilled to announce the integration of Zeebe endpoints into Camunda 8 REST API, aimed at enhancing your experience in building process applications. This will ease the installation and onboarding to Camunda 8 as gRPC won't be required anymore. With the introduction of Zeebe endpoints in REST API, we're eliminating the need for gRPC, reducing friction in adoption. Developers can now seamlessly transition from gRPC to REST with the assurance of having the same endpoints, thereby saving time and effort. Use officially supported Camunda SDKs to have an easy migration journey.
User Stories 🧑🚀
Implementation 👷
This product iteration contains increments 4-7 from this document.
Infrastructure topics
Endpoints we will migrate
We do not plan to migrate the Job Streaming API - it will remain as a gRPC endpoint.
DRIs
Discovery phase: @aleksander-dytko
Define and Implement phases:
Overall contact point and DRI: @tmetzke
UX Flow and UI Designs: not needed
Architecture Solution Design: @romansmirnov
Epic coordination across teams: @tmetzke
Component A - implementation & documentation & component testing:
if neededComponent B - implementation & documentation & component testing:
if neededDocumentation - guides:
if neededE2E Testing:
if neededValidate phase:
required:robot: This issue is automatically synced from: source