Re: REST; good for humans and machines

On Sat, Jan 04, 2003 at 04:08:51PM -0700, Champion, Mike wrote:
> > That REST was believed for humans is, as I understand it, why Web
> > services were created in the first place.  If it's also for machines,
> > then what we've got here is two ways of solving the same problems.
> 
> What's the other way ... certainly you're not lumping all things non-RESTful
> into one category?  There would appear to be a myriad of ways of solving the
> same problem.

My bad.  I should have said "two architectural styles which can solve
the same problems" (assuming Web services have one architectural
style).

> > At the very least, this should come as a surprise to the WSAWG, no?
> > Thoughts?
> 
> Uhh, maybe a year ago this would have surprised many of us.  The REST meme
> is in pretty wide circulation now.  I think we're also coming to an
> understanding that the "REST is for humans" thing is a red herring; the

Really?  I keep hearing it over and over, even in this recent
discussion.

If it's true though, it would certainly be good news!

> question of how one imputes the semantics of a web page or web service
> invocation is orthogonal to the question of the architectural style.  Still,
> somehow or other the contents of a message have to be mapped onto something
> that a machine can understand.  The "classic" SOAP/WSDL paradigm does this
> more or less mechanically, trusting some human programmer to make sure that
> the functions and arguments "mean" the same thing on both ends.  REST,
> AFAIK, simply says nothing at all about this.

Hmm, no, I don't think so.  That's what the uniform interface is for.
It's about generalizing the problem down to a common set of semantics.
So "getFoo()" gets generalized to "GET", "setFoo()" gets generalized to
"PUT", etc..  That's the mapping you're looking for, I believe.

> I think it's pretty clear to most who have followed the "REST vs whatever
> the alternative is" megathread that one can build a RESTful solution to just
> about any distributed computing design problem.  One can also (I think)
> built an RPC, or asynch document messaging, or tuple space, etc. etc. etc.
> solution to just about any distributed computing design problem.  This

Agreed, but again, I don't think many Web services proponents believe
this.

> leaves us with a number of questions that don't seem to have clear answers
> at the moment:
> 
> - Which of these is most likely to be optimal under different scenarios
> (different networking environments, user requirements, assumptions about
> homogeneity, availability of out-of-band discovery mechanisms ....)?

Exactly.  Which architectural style has the necessary properties?

We know REST does, because the Web demonstrates that.

> - How can we conceive of the components and interrelationships in a web
> services architecture that allows various features to be re-used in
> different applications with different architectural styles?

Whoa!  Come again?

 [1] http://www.w3.org/DesignIssues/Evolution.html#PartialUnderstanding

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis