Чтобы избежать постепенного внедрения вашего собственного пользовательского REST API-интерфейса camunda поверх JAVA API, я бы выбрал 1 (использовать REST API напрямую), когда это возможно. Таким образом, вы также можете использовать новые функции продукта, не добавляя новый собственный код, и избежать усилий по обслуживанию / обновлению.
Однако вы можете встретить случаи, когда составная служба (данных) объединяет API продукта (получает переменные процесса, включая первичный ключ для объекта данных) с собственной (персистентной) логикой c (например, выборка объекта JPA по этому первичному ключу) может быть желательной.
Некоторые люди предпочитают, в принципе, создать свой собственный фасад сохранить базовую реализацию заменяемой. Исходя из моего опыта, эти усилия и последующие постоянные усилия не оправданы. В любом случае замена базового механизма потребует усилий.
Службы REST камунды также можно комбинировать с вашими собственными службами в рамках того же API (url).