Proposal: Link header in responses to AutomationRequest creation

[Samuel Padgett <spadgett@us.ibm.com>]

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