[Oslc-Automation] Changes I have made to Actions specs based on Actions issues list

[John Arwe]

[in cheesy chop-socky movie style] What?!?  You dare question the spec-fu 
master?!?  [lips keep moving for another 5 seconds]

Base Automation (2.0) allows producers to return a 200 in cases where they 
return a request+result and the result has already "finished" [3].  See 
[1], [2]; we have implementations using this since 2.0 - it's somewhat 
popular in operations actually, where the duration of the plan's execution 
varies widely based on parameters ... hitting one endpoint is quick, 
hitting 10K of them... less so.

We oscillated wildly during 2.0 drafting on the subject of how "obvious" 
to make this case; it's really just an optimization of the "more 
traditional" 201/poll Automation flow, so we ended up being fairly low key 
about it.  If you look at the wiki history for section [3] you'll see how 
it waxed and waned.  One of the "optimizations" inherent in using 200 
instead of 201 is that there is no need (with 200) for the provider to 
persist the request+result representation at all (although it's still free 
to); as far as the client is concerned (a) there is no need/perhaps 
ability to GET/poll for it (b) there is no need to DELETE it.  So it saves 
at least 2 HTTP flows over the normal case, with all that implies.


[1] 
http://open-services.net/wiki/automation/OSLC-Automation-Version-2.0-Samples/#Example-2
[2] 
http://open-services.net/wiki/automation/Synchronous-Execution-Scenario/
[3] 
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.0/#Asynchronous-and-Synchronous-Automation-Execution

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

> > A FB-200 means "I did it" 
> > (past tense, otherwise it should be a 202).  A AR-200 means "I 
> > created the AR, now you [consumer] monitor it until state/verdict 
> > say it's baked".
> 
> I would expect AR factories to return a 201 Created response code. 
> Appendex A states: 
> 
> http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-
> RDF-resources/#constructing-http-requests 
> "201 (Created) to indicate that the request resulted in the creation
> of a new resource; the Location response header provides the URL of 
> the newly created resource. The client is responsible for 
> interrogating the resource’s state to determine whether or not the 
> action has completed. One use of this in certain profiles is to use the 
> OSLC Automation specification’s mechanisms to monitor its progress 
> and success/failure." 
> 
> So the only issue, as I see it, is if providers respond with a 200 
> when it has created an Auto Request, which I would consider to be 
> bad practice anyway (I haven't checked if the spec says what 
> response code it should use, but I woudn't be suprised if it doesn't 
say). 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/ee80c8da/attachment-0003.html>