>  From: Thomas B. Passin [mailto:tpassin@[...].net]

<snip/> 

>  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.

Yes, I've heard this mentioned before. This is an intriguing approach. I
also saw someone mention in a post (was it on the rest-discuss list? I can't
find it now) that it is reasonable to return a 202 Accepted status. Is this
compatible with the approach of returning a location for a created resource,
or do I need to return a CREATED status for that? (I was thinking about this
just last night, and I'm fuzzy on this.)

However, there are still instances where you just need a synchronous reply.
One scenario I can think of is authenticating a user against a remote
service. We do single sign-on with remote portals routinely. In such
deployments, when the user tries to access our software and they have not
been authenticated, we will authenticate them using the remote service
before allowing entry. We obviously can't do this in an async fashion.
(Currently, we typically do this with browser redirects and unique URIs with
encrypted tokens. But there is a need to do this sometimes with XML
messaging, as well.)

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>