Re: [oslc-automation] Fw: Proposal: Link header in responses to AutomationRequest creation

[Steve K Speicher <sspeiche@us.ibm.com>]

+1 to the proposal to provide a solution
that doesn't require query support.

I think Sam may be understating the
optimization, in that not only during runtime does it save the client making
the additional request but the optimization is key for time from going
from no-OSLC support to an OSLC-supported solution.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net



From:      
 Martin P Pain <martinpain@uk.ibm.com>
To:      
 oslc-automation@lists.oasis-open.org
Date:      
 12/02/2014 05:10 AM
Subject:    
   [oslc-automation]
Fw: Proposal: Link header in responses to AutomationRequest creation
Sent by:    
   <oslc-automation@lists.oasis-open.org>

---

Forcing OSLC Automation servers to implement
a full query engine seems like too high a barrier for entry, when the standard
interaction only requires the client to be able to find a result for a
given request. 

Please read & comment on the proposal below. 

Thanks, 
Martin

----- Forwarded by Martin P Pain/UK/IBM on 02/12/2014 10:09 -----

From:        Samuel
Padgett <spadgett@us.ibm.com> 
To:        oslc-automation-comment@lists.oasis-open.org
Date:        20/10/2014
18:23 
Subject:        [oslc-automation-comment]
Proposal: Link header in responses to AutomationRequest creation
Sent by:        <oslc-automation-comment@lists.oasis-open.org>

---

Currently, as I understand it, Automation clients must query to find the
AutomationResult for an AutomationRequest they created. Something like

oslc.where=oslc_auto:producedByAutomationRequest=<request-uri>

This requires at least two requests, one POST for the AutomationRequest
and one GET to find the AutomationResult. It also forces servers to support
OSLC query. As someone who has written several OSLC providers, I can say
query is a lot of work to implement and difficult to get right.

I propose we add an optional Link response header [1] in responses to OSLC
AutomationRequest creation. This is an optimization to remove the query
step. For example, 
HTTP/1.1 201 Created
Content-Length: 0
Link: <http://example.com/auto/result/82>;
rel="http://open-services.net/ns/auto#produces";
anchor="http://example.com/auto/request/82"
Location: http://example.com/auto/request/82

Here a client can discover the AutomationResult just by looking at the Link headers on the POST response.

We could relax the MUST requirement for queries if a provider supports the Link header. Providers that don't immediately create an AutomationResult for an AutomationRequest could leave off the Link header and continue to use query.

Link is used in several places in LDP 1.0 [2], and we've used it in OSLC 3.0 resource preview drafts [3].

[1] http://www.ietf.org/rfc/rfc5988.txt
[2] http://www.w3.org/TR/ldp/
[3] https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/resource-preview.html?rev=42&sc=1#linkHeader
--
Samuel Padgett | IBM Rational | spadgett@us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC
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