* bierstuebl <bierstuebl@...> [2008-09-08 03:10]:
> I would like to use asynchronous REST by POSTing a request to
> e.g. /backups (for creating a new backup version), which will
> return me a 202 with a location in the header.

RFC 2616 does not specify a meaning for the Location header in
the context of a 202 response, so do not expect clients to know
what to do with your response.

Instead, the body of your response should be machine-readable and
should contain links to a) the eventual location of the resource
if you already know where it is going to be and b) the location
of a resource that can be polled for the status of the operation
in the meantime. These links should be annotated so that the
client knows which one is which.

Using hypermedia (put plainly, “stuff with links in it”) in this
fashion is the cornerstone of REST.

> What should this location look like? I think it should look
> like /backups/version_x and NOT be somewhere else like
> /queue/backups/version_x or the like. However, if a client
> starts polling now on /backups/version_x and the process hasn't
> finished yet, what should be returned? A 404 with a body until
> the process is finished an the real representation can be sent
> with 200?

Sending 404 while the target resource does not yet exist is fine.

Do not expect the client to poll the target resource though. For
one thing, this protocol gives you no way of signaling the client
that there was a problem with processing that you only discovered
later.

Worse, though, all this means you are overloading the meaning of
202, Location and 404 with semantics outside HTTP’s uniform
interface, implementing a private protocol. In REST, when you
need to provide semantics that aren’t directly available at the
protocol level, your first instinct should be to expose another
resource; and the way to make that all work together is to a)
provide links to clients, that b) have annotations saying what
semantics the client can expect that resource to expose.

> Using a new resource like /queue/backups/version I could return
> a 200 with some status information in it. However, the client
> initially requested a representation of a backup, but when it
> starts polling on the new resource it receives another
> representation, the a status representeation. How could a
> client adjust to this situation without knowing in advance that
> the action would be asynchronous??

It can’t. You want to do something that HTTP has no provision
for, so any client that is to successfully follow your protocol
will need special knowledge about it. However, by staying within
the confines of the uniform interface and hypermedia, you can
contain the spread of that special knowledge to a minimal amount
of code, and you maximise the amount of accidental usefulness
that clients without knowledge of your protocol can still get
out of the service.

And that is the goal of REST: minimising coupling.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>