I was asked today at the end of the presentation about what we thought an Async REST service would look like. At the time I was not sure; but after thinking about it the pattern is probably quite simple.
Consider an business making an insurance claim of some kind on behalf of an employee. So the client sends a POST message to the insurance resource as it want to create a new insurance claim. In the message it contains not only a reference to the resource for the employee but also a new sub resource for the employee that represents the claim. Since we are doing async the server response with 201 and with a URI to a resource to represent the insurance claim.
Eventually the server processing the work will POST its response back into the particular claim resource which we specified on invocation. In my example the message contains a reference to the insurance claim; but I suspect this is not required as would be implicit in the use of the resource on the client.
Now since the response is a POST as well it creates a new resource, in this case a claim response, which is returned to the server. In my experience insurance claims often take multiple goes so there could be multiple responses for a give claim. This would appear to complete the asynchronous message exchanges.
Does appear to make sense, mind you it is 00:30 at the moment so I will have to review in the morning, and all without the use of any WS-* standard.