It is possible to create a process instance with a businessKey. The ID is generated based on this key and then the user can access the resource by either using such id or the business key. The business key is provided using a query parameter in the POST request.

POST /myprocess?businessKey=TEST-0123

Then the process instance will have a businessKey attribute with value TEST-0123 and an id with value ec27d949-8099-31a3-8fc8-9230ff4dbe87 allowing the api consumers to access the resource by using either of them.

GET /myprocess/ec27d949-8099-31a3-8fc8-9230ff4dbe87

GET /myprocess/TEST-0123

The uuid is generated if the provided id throws an exception when creating the UUID from a String and the resulting API can be confusing, why 2 different endpoints return the same resources? The API cannot be considered consistent.

Proposal:

• The user is free to provide an ID. This ID must be unique and will be used to access the resource. That means the businessKey is no longer meaningful and can be deprecated (or removed).
• The custom ID will be provided as a PUT to /myprocess/{id} and will create the resource if it didn't exist but will update the model if it did. Currently POST is used for that purpose.

Accepted solution:

• Id is detached from BusinessKey and will always be generated.
• Business Key is still received as a Query Parameter and stored in the process model.
• Business Key is still accessible through Data Index

Additional changes to the REST API:

• Resource creation returns a 201 instead of 200. The ID is returned in the Location HTTP Header
  • This affects the Link HTTP header returned when creating a new Human Task instance
• Updates are done through PUT
• Service invocation (e.g. Decisions) is not considered a resource creation and will be done using a POST that returns the resulting object.