Still working this very simple automation implementation. 1: My client creates an Automation Request via the factory. 2: ? 3: My client GETs the corresponding Automation Result to see if has finished, etc.
In step 1, client POSTs an AReq representation to the creation factory URL. The 201 response is a pointer (HTTP Location header) to the newly created AReq. At some future time, it wants to poll and see if the request has completed (generically, what is its current state). By what magic in step 2 does it find the ARes's (sic) URL? I had expected a link from the Request to the Result, but I see none (I see the opposite link). Is the expectation that the client has to query the AResult collection using the query parameters (where) to find the AResult corresponding to the request, and no other implementation models need apply? In the simplest possible case, the request could have already completed by the time the create-request flow is ready to build the response. It would be nice if the 201 response did not require any additional flows for the client to examine the AResult. Core and HTTP would let me provide a 201 response, Location=ARequestURL, body=AResult (sic), which accomplishes that (without forcing it on anyone - clients preferring to query still could, and ignore this "optimized" case). Which is nice, but does not address the mainline case where completion really is asynch. If the spec's current intent is to require that clients can search through Results via query capabilities, I don't think the spec actually says that. It says >=1 QC is required, but not which resource types that QC is required to expose. Creation Factories are likewise pretty open; >=1 is required, but no restriction on what types it manufactures. ARequest seems likely (in addition to just intellectually, also by inference from the SHOULD on delegated creation dialog). Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
