RE: Protocol independence

>  I fully agree with 
> much of the 
> REST position when you talk about the advantages of 
> leveraging the HTTP 
> infrastructure in a way that exploits it in specific 
> applications(e.g., by 
> using GET to get things over the Web, so as to exploit caches 
> and allow 
> hyperlinks), but I simply don't understand this concern with the 
> relationship between the methods of the message transport 
> mechanism and the 
> operations implied by the content of the message.

"the methods of the message transport mechanism" *ARE* the
"operations implied by the content of the message", at least
when the "message transport" is an application protocol.

That's why protocol independence for application protocols, seems
such a nutty requirement from my POV.

> HTTP GET 
> probably makes 
> more sense for the canonical getStockQuote use case, but that's an 
> engineering decision by an implementer, not an architectural 
> decision for 
> the Web services community.

I disagree very strongly.

The choice to use GET vs POST to retrieve stuff is most
definitely an architectural decision, because the properties of
the architecture depend on that choice.  If you choose to use GET
to retrieve data, your system demonstrates greater visibility than
if you were to use POST.  That's why the TAG says stuff like;

  "Safe operations (read, query, view, ask, lookup, etc.) on HTTP
  resources SHOULD be implemented using GET"
  -- http://www.w3.org/2001/tag/doc/get7

Now *that's* architectural guidance! 8-)

> I use SMTP to retrieve things all the time!  
> mailto:somebody@somewhere.com - 
> - "Uhh, I can't get to that document on your intranet ... 
> could you please 
> send it as an attachment?  Thanks."  Why shouldn't a machine 
> be able to 
> mail another machine to request that some information be 
> sent?  Why should 
> a web service back end care whether the request came in over 
> SMTP or HTTP 
> or MQ or JMS or hyperwave or snail mail?

Ok, nevermind.  Stuart Williams and I went down that path a couple
of years ago, and bumped into Turing.

MB

Received on Friday, 4 April 2003 14:00:23 UTC