Re: Proposed text for section 1.6.2 and 1.6.3

On Wed, May 07, 2003 at 05:00:30PM -0400, Champion, Mike wrote:
> > I'm surprised to see that distinction drawn.  I think it's quite clear
> > that RESTful Web services can do that too, because I order 
> > books through
> > my browser, and people move around to deliver me those books as a
> > result.  8-)
> 
> I'm struggling with the idea that an API SOA would invoke some code that
> causes the books to be shipped, and a REST SOA would manipulate an
> information resource that a human or software agent could interpret as a
> request to ship the books.

That doesn't seem to be an apples-to-apples comparison though.  I'd
say that both styles could be described in either of those terms.

But if I understand what you're getting at, I'd say that in both cases
the code behind the interface would "cause the books to be shipped".
The difference is that with the REST approach, the orderBooks() method
is invoked by the code behind the POST (i.e. the code that puts that
system "on the Web"), whereas with API SOAs, orderBooks() is invoked
directly.

That's probably not the kind of difference you had in mind though, so
I don't know what to say.  I will say, that in your response to Walden,
you mentioned that you felt that application state was an important
difference, but I wouldn't say so; API SOAs are often stateless.

>  I admit that this distinction is a bit
> metaphysical ... but so is much of the "REST SOA vs API SOA" discussion :-) 
> Perhaps just saying it this way is clearer than what I had drafted.  I do
> NOT want to perpetuate the "REST is only for humans" misconception, I assure
> you!

Thanks.

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

Received on Wednesday, 7 May 2003 22:00:32 UTC