Re: REST wrap-up (was Re: Web Services Architecture Document

I have held up responding to this; but I don't think its fair that Mike 
and Roger take all the flak!

I believe, fairly strongly, that had the RESTafarians made a genuine 
and compelling case that *their* constrained interface actually fitted 
the requirements then it would have been adopted. However, that never 
happened, and worse, the RESTafarians seemed to blame the WG for their 
presumed lack of perspicacity.

Lacking such a case, the fall back position is the one adopted 
(unconsciously perhaps); let a thousand flowers bloom in the interface 
era.

Architecturally, SOAP offers considerable and interesting advantages 
over Plain-Old-XML (sorry BT): it allows the different semantic aspects 
of a message (not only security, transactions and routing but also 
potentially customer information and credit card details) to be placed 
in well known locations  -- enhancing the so-called visibility of the 
communication.

Intermediaries are probably the least well understood but most 
important features of SOAP. We have gone to a lot of trouble 
incorporating them in a smooth way.

What I am trying to say is that the WSA represents genuine progress 
(IMO) in the field of large scale systems. Is it complete, no. Is it 
useful, we all hope so.

Going back to the issue of constrained interface; I think that most 
professionals would agree that a well-designed constrained interface is 
a wonderful technique for realizing interoperability. The critical 
phrase is, of course, well-designed. I don't question the quality of 
the REST design. Simply, that it leaves so many questions unanswered 
that it is dwarfed by them -- in the realm of service rather than 
hyper-text.

I fully understand that my comments above might be regarded as 
inflammatory to some. However, as any real evangelist will tell you, it 
is the responsibility of the faithful to demonstrate the superiority of 
their chosen path. Proof by declamation is not the same thing as proof.

Finally, I would like to plug some thoughts of my own. In order to 
achieve genuine interoperability, across ownership and trust 
boundaries, a few simple questions need to be answered:

What are you (the other application) talking about?
What are you supposed to do, and what can I do, when?
Who are you anyway?

I think that it is important to observe that not just any answer to 
these questions will do. They need to be answered in a way that meshes 
with the way that people use and program computer systems.

A *constrained interface* that is coherent with this view would, in my 
opinion, be a great tool for achieving interoperability. Anything less, 
will be,...less.

Frank


On Feb 6, 2004, at 1:46 PM, Mark Baker wrote:

>
> Thanks Roger (and Mike), for those answers.  They were just what I was
> looking for, again.  I apologize for not asking them in the first round
> of questions, but it only occurred to me afterwards that they wouldn't
> provide me all the information I needed to really understand where 
> folks
> were coming from.
>
> I presume you won't mind if I don't turn this into a thread 8-), but
> just for the record, as you summized, I'm not in the a) camp, as my
> understanding of software architecture tells me that some architectural
> styles are not suitable for some domains (like the Internet).  I'll 
> just
> briefly mention again, that if you study enough Internet scale systems
> (email, Web, instant messaging, even the telephone network), you'll 
> find
> that they *ALL* have one thing in common; a constrained interface
> derived from an application abstraction (respectively, an inbox, a
> resource, a user, and a telephone line).  I don't believe that's a
> coincidence.
>
> Cheers,
>
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>

Received on Sunday, 8 February 2004 23:16:52 UTC