[Oslc-Automation] Changes I have made to Actions specs based on Actions issues list
John Arwe
johnarwe at us.ibm.com
Thu Mar 13 10:56:33 EDT 2014
I'm saying:
1: When it is the case that the request has completely finished by the
time the server sends its response, then it has a choice of status codes:
1a: 200 is appropriate when the server has no intention of persisting the
entity in the HTTP response; its response must be multityped as both
AutomationRequest and AutomationResponse *and* entity's state must be
"finished" (as defined by Auto 2.0) . Since (as far as the client can
tell) nothing was created, the client has no subsequent responsibility to
delete anything... and, indeed, it receives no URL from the server against
which it would use in a subsequent DELETE request; it could attempt to use
links in the response entity or a query, but there are enough "not Must"s
in 2.0 that it is not guaranteed to find such a URL if it did try.
1b: 201 is more appropriate in all other Automation-governed cases. The
201-Location's resource can be anything allowed by Automation, which
includes but is not limited to case 1a.
The 201 Automation-governed qualification is because I can see the
*potential* to use AutomationRequest's in ways other than what the
Automation spec defines, for example in a generic 202 response entity as
we've discussed before. But that's outside Automation, hence outside the
scope of this discussion.
2: We have concrete cases where 200 was anticipated [2], and where it was
shown as a potential consequence of 2.0's content [1].
3: I am confirming that the concrete cases have in fact been implemented,
and there is a deployed base of exploiting products currently in
operation.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Martin P Pain <martinpain at uk.ibm.com>
To: John Arwe/Poughkeepsie/IBM at IBMUS,
Cc: oslc-automation at open-services.net, "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
Date: 03/13/2014 09:37 AM
Subject: Re: [Oslc-Automation] Changes I have made to Actions specs
based on Actions issues list
So are you saying "We have concrete cases for 200 - but in those cases the
action has completed, so there's no bug",
or are you saying "We allow providers to return 200, but don't define in
the spec what that means so it could mean anything, so the bug stands"
Do we have any concrete cases for a 200 being returned when the Result has
not been finished?
or are you saying "We allow providers to return 200, and it's possible
that that could mean it hasn't finished, but it's unlikely that that will
happen (or that's base use of the HTTP return codes) so it's the
provider's problem not the specs - so there's no bug"?
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair
E-mail: martinpain at uk.ibm.com
Find me on: and within IBM on:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
From: John Arwe <johnarwe at us.ibm.com>
To: oslc-automation at open-services.net,
Date: 13/03/2014 12:13
Subject: Re: [Oslc-Automation] Changes I have made to Actions specs
based on Actions issues list
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
[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).
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/1de09f6d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/1de09f6d/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/1de09f6d/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140313/1de09f6d/attachment.gif>
More information about the Oslc-Automation
mailing list