Re: REST, Conversations and Reliability

"Newcomer, Eric" wrote:
> 
> A couple of brief notes...  Transparent reliability mechanisms are 
> well established in distributed transaction processing systems.

Not in those that work at Internet scale across trust boundaries.. 

> The issue with sending the same message 1 or 10 times is related to 
> the update of related state, such as a database.  You may be able 
> to tell with a GET whether the receiver has received the state, 
> but there's no way to know whether the database has been updated, 

GET reflects what is in the database! After all, what is in the database
is all that is of interest.

>and whether or not sending the message again may cause another update 
> that destroys data consistency (i.e. adding the same amount twice 
> to the same account).

That application protocol can define this. HTTP does. 

> We are discussing all this, as someone correctly points out, 
> because traditional mechanisms for ensuring message reliability 
> relied on transport level semantics missing from HTTP.

If you use HTTP as an application protocol rather than a transport
protocol then you do not have these problems. GET returns the right
thing. Your choice of HTTP method declares whether repeatability is
safe. etc.

> This is one of the key issues for Web services, since many so 
> called additional features and functions (security, transactions, 
> reliability) typically rely on transport level semantics to be 
> propagated and processed correctly.  These are provably not 
> application issues.

If you handle these things in a stateless, resource-centric manner then
they will not depend upon reliable messaging.

> The ideal solution would be to use BEEP or create a SOAP level 
> application atop TCP/IP.  But it seems we are stuck with HTTP 
> since it's so widely adopted, and we need to think of 
> mechanisms that take into account HTTP's limitations.

If you use HTTP as HTTP you won't find it limited (or unreliable). If
you use HTTP thinking it is a firewall-friendly variant of TCP, then you
will.

> Using URIs as simple unique identifies as namespaces do 
> is an acceptable alternative to GUIDs, but not if we expect 
> anyone to be able to perform a GET on them.

Why not? That's the whole point!

> As Sam Ruby pointed out in his paper on REST + SOAP [1], HTTP works 
> great for "read mostly" applications, but breaks down when used 
> for updated intensive applications.  

If that's true, could you explain Expedia, Ebay and writetheweb.com?
Please don't say "there are humans involved" unless you can explain how
humans can turn unreliable protocols into reliable ones (despite the
fact that humans tend to be less reliable than computes) and can turn
read-mostly protocols into read-write ones. Please also define
"read-mostly". I thought that supporting writeback was a boolean
condition.

>...
> Ok -- bonus points to RESTafarians who can answer this one -- when 
> is an RPC less expensive than a local procedure call?  (Please, 
> no OMA or DTP folks are eligible!)

Trick questions? There are a variety of answers but I choose: "When the
remote process can accomplish a task more cheaply than any local
process."
-- 
"When I walk on the floor for the final execution, I'll wear a denim 
suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
-- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
Congressman James Traficant.

Received on Monday, 19 August 2002 11:34:06 UTC