Modify existing task API to update task model on generated resource for process

As part of functionality alignment between v7 and kogito, it would be nice to have the possibility of updating task model without changing the phase.

To achieve that goal, I propose to change current interface

@POST
 @Path("/{id}/firstLineApproval/{workItemId}")
 @Consumes(MediaType.APPLICATION_JSON)
 @Produces(MediaType.APPLICATION_JSON)
 public ApprovalsModelOutput completeTask_firstLineApproval_0(@PathParam("id") final String id, @PathParam("workItemId") final String workItemId, @QueryParam("phase") @DefaultValue("complete") final String phase, @QueryParam("user") final String user, @QueryParam("group") final List<String> groups, final Approvals_1_TaskOutput model) {}
 

by removing query parameters (phase, user and groups), add phase into a new TaskParameters class together with the generated output model , so the method will look like

@POST
 @Path("/{id}/firstLineApproval/{workItemId}")
 @Consumes(MediaType.APPLICATION_JSON)
 @Produces(MediaType.APPLICATION_JSON)
 public ApprovalsModelOutput changePhase_firstLineApproval_0(@PathParam("id") final String id, @PathParam("workItemId") final String workItemId, final TaskParameters<Approvals_1_TaskOutput> model) {
 

Another option to avoid mixing phase with the model in the body  will be to use two different APIS, one that includes the phase as resource and body as model to update phase and model

@POST @Path("/{id}/firstLineApproval/{workItemId}/phases/{phaseId}") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public ApprovalsModelOutput changePhase_firstLineApproval_0(@PathParam("id") final String id, @PathParam("workItemId") final String workItemId, @PathParam("phaseId") String phase, Approvals_1_TaskOutput model) {
 

And change semantic of the existing API to ignore phase parameter, so it will just update the model

Both approaches (phase as body or phase as resource) will be breaking backward compatibility with 1.0 API.

We can also took an intermediate approach, which preserves most of backward compatibility. Add phases resources API  as described above, keep current API behaviour as it is  (ignoring query parameters), so it invokes complete phase. And, in order to update model without changing phase, use /phases resources with no parameter.

If it is a mandatory requirement to keep STRICT backward compatibility, then we can leave query params and introduce a new value for phase (something like "_none") which meaning will be "no phase transition", but I honestly think we should break backward compatibility here (which will be break anyway is we eventually took the user from auth context as we should do)