Description of problem: I may have misunderstood whole workflow around scheduling operation via REST API. But I don't like it and I think it is too difficult for client.


Version-Release number of selected component (if applicable):
RHQ 4.8


This is how operation scheduling on resource can be done now:

I have a resource with ID. 
 - I need to lookup operationDefinition for particular resource.
GET operation/definitions?resourceId=<ID>

I have operationDefinition, I need to create a draft operation
 - I need to create a draft operation by
 POST operation/definition/<OP_DEF_ID>?resourceId=<ID> with empty body
 as a result I get operation with a new OP_ID

Now, having operation body, I can put/change input parameters

 - I need to schedule operation
PUT operation/<OP_ID> with operation in body - I need to set special property called 'readyToSubmit' to True otherwise operation does not get scheduled and this PUT operation serves something like editor .. where I can prepare my operation (I don't see a good usecase for this)

Once I've scheduled operation i can read link to operation history from response body, so I can track status and wait for result.


First of all we're breaking REST recommendation by using PUT to modify draft-operation state not to create a resource. Concept with 'readyToSubmit' is IMHO not a good idea. There's no reason why server should keep state of operation before it is scheduled.

2nd thing is, that this concept can be hardly easily extended to support group operations or scheduling via cron.

My suggestion: a new workflow (+- completely redo operation workflow):

Looking up operation defintion could remain same

using GET /operation/definition/<OPDEF_ID>/draft you can get a draft operation body - this is nothing more than operation definition "translated" to operation - parameters with defaults

using POST /resource/<ID>/operation/schedule/<OPDEF_ID>/schedule schedules operation instantly

using POST /resource/<ID>/operation/schedule/<OPDEF_ID>/<timestamp> schedules operation in given time (must be future)

IMHO it makes sense to "duplicate" operations under resource, because scheduling a operation is connected to resource, it's definition is connected to resource and operation history as well.

I'd introduce

GET /resource/<ID>/operation returns same as /operation/definitions?resourceId=<ID>
GET /resource/<ID>/operation/history - returns history of all operations on given resource
GET /resource/<ID>/operation/<OPDEF_ID>/history to return history items for given operation definition id
GET /resource/<ID>/operation/history/<history ID> to return history for given history ID


Basically, I'd like to get rid of creating a draft resource on server and 'readyToSubmit' key within operation body. In future we may add various scheduling options (repeat options or cron) into operation body or as a query params when scheduling operation and .. if we decide to nest operations under resource, we may do the same for groups.