[
Lists Home |
Date Index |
Thread Index
]
[Michael Brennan]
> > From: Thomas B. Passin [mailto:tpassin@comcast.net]
>
> > 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.)
>
Well, if the server created a new resource, you probably want it to inform
you so you can access it. From RFC 2616 (talking about POST requests):
"If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30)."
This is just what we need for asynchronous operation. A 202 would be OK
except that it gives you no information about any new resource. If no new
"subordinate" resource was created, the RFC says:
"The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that
describes the result."
> 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.)
>
It seems to me that when you need a synchronous reply, you just operate as
usual, like you are already doing, since the basic HTTP operation is
request/response.
Cheers,
Tom P
|
