[
Lists Home |
Date Index |
Thread Index
]
[Michael Brennan]
> > From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>
> <snip/>
>
> > One easy way to solve this problem is by decoupling the
> > request from the
> > response. Send a request (with an indication of how to
> > respond....a URL, Web
> > Services Callback, and email address etc.) and receive a "transaction
> > received" HTTP response (which should be almost immediate).
> > Some time
> > later the service uses the response indicator info to send a
> > "real" response to
> > the transaction. Damn....that sure sounds like message
> > queuing doesn't it?
>
> That's the right way when you can get away with it. But some interactions
> can't afford an open-ended contract for when the response finds its way
back
> to the originator of the request.
>
There's another way to approach it that is more consistent with the HTTP
RFC. When you POST data to a server at a URI, one of the possible intended
outcomes is that the server should create a new resource that is
"subordinate" to the originally addressed one. If so, it should return a
CREATED response with a URI for the new resource.
For example, if you requested a transaction at
http://www.illustations.com/bookstore/the_latest_book
you might be informed to look for your results (tracking notification for
the shipment, perhaps) at
http://www.illustations.com/bookstore/the_latest_book/shipment/some_tracking
_number
(This certainly should count as a "subsidiary" resource)
If the server cannot return a response immediately, then, it fits the
concept of operations for the server to return a CREATED message that says
when it expects the new resource to contain the data, and what url it will
be at. The requestor can then GET that resource whenever it desires,
checking to see if it has been completed yet.
By the same token, the original POST could have contained a specification of
the maximum allowable time for the results to be ready, if that were
important.
This also would work well with SOAP, letting you use just its messaging
capabilities without any RPC function invocations.
This fits the RFC conops, the REST architecture, and yet is not message
queueing and is a lot simpler than message queueing. Of course, for this to
work, both parties must be able to know what to expect and how to designate,
for example, the max allowable time. These are a few of the "contract"
issues that Len has been emphasizing.
Cheers,
Tom P
|
