In camunda 7 we could use history service and business key to check where a process instance with particular business key already exists for a process definition.
In Camunda 8, this kind of request would go to the Operate REST API.
The reason is that Zeebe can by design not expose the internal state. Also, it does not contain any historical data, only the runtime state.
One difficulty with this requirement could also be that you search by business key which does not exist in Camunda 8. Instead, you would use a variable you can refer to as business key.
I would suggest to use:
GET /variables → query for the name and value of the business key variable
GET /process-instances → query for the returned process instance keys from the first request with the bpmnProcessId
I know this is verbose right now, but we plan to allow searching for process instances by variables.
The requirement is to create a process instance provided a process instance with same business key does not exist.
For operate API POST /v1/variables/{key}, the challenge is it requires a key, based on which it searches. Not sure what this key represents, thought it was process instance key but trying on swagger did not return expected result.
For operate API POST /v1/variables/search, it will search the entire space which will be slower and more work would be required to meet the requirement.
the key in the first endpoint you mentioned is the variable instance key.
The second query is exactly the one you require. As the search is performed against an Elasticsearch database in the end, the query is still very fast.
Hint: If the requirement does only affect running process instances (do not start a process instance with the given business as long as there is another process instance running with the same), you can use the Single Instance messaging pattern: