RE: [Fwd: A modest proposal for an OpenSocial RESTful API]

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Roy T. Fielding wrote:
> The requirement should have been on the recipient of 
> pipelined requests.
> Namely, each request must be handled in the order received 
> and responded to in the same order, with one exception: any 
> sequence of requests consisting entirely of known safe 
> methods (e.g., GET, HEAD, OPTION,
> TRACE)
> may be processed in parallel provided that the associated 
> responses are still delivered in the order received.

That is how it should be. As it is, pipelining cannot be used to batch
any requests that have ordering constraints.

> it doesn't prevent applications from using their own 
> out-of-band information to recover from failures.  For 
> example, an automated Atom feeder is fully capable of 
> discovering whether a POST succeeded or not, automatically 
> and without user input, even if the connection goes away.  
> The same is true of any authoring protocol that allows 
> discovery of versions.

With AtomPub you cannot tell if a POST succeeded or not unless you get
the response back from the POST:

(1) The server can delete or replace any identifying information from
the entity you POSTed. Some (most?) AtomPub servers replace the atom:id
and strip out extensions they don't understand. So, you cannot just look
at the collection feed to see if the entry you posted showed up there.

(2) AtomPub servers are not required to update the collection feed
synchronously with modifications made by clients. If the collection feed
is updated on a time interval, then the client would have to wait until
the next interval to check for the new entry. But, then it runs into
problem #1.

- Brian