W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Summing up on visibility(?)

From: Miles Sabin <miles@milessabin.com>
Date: Fri, 10 Jan 2003 11:25:56 +0000
To: www-ws-arch@w3.org
Message-Id: <200301101125.56234.miles@milessabin.com>

Mark Baker wrote,
> The hard part is obviously determining *which* URI to POST to.  This
> requires a priori knowledge too, of course; the automaton has to know
> what a "reviewer" resource is so that it can be informed that "this
> URI identifies a reviewer".  Miles and I weren't able to agree that
> this type of a priori knowledge is any different than the a priori
> knowledge required to invoke a "review()" method, so I won't reopen
> that one.  Suffice it to say that this is an alternate means of doing
> the same thing, while respecting the uniform interface constraint.

I'm happy to agree that it's _different_ a priori knowledge.

I was under the impression that you were denying that this was a priori 
knowledge at all, or at least that it was irrelevant to the comparison 
between REST and the alternatives. If that was a mistaken impression, 
then thanks for clarifying your position.

The question for me then becomes: are the a priori knowledge 
requirements for the REST architecture more, equally or less demanding 
than those for the alternatives?

Given that the these requirements relate to the functionality of the 
system, what it does, I would say equally (albeit differently) 
demanding. If we have two implementations of the same system, one 
RESTful, the other not, _both_ have to do the same job, so both have to 
encapsulate the same knowledge in some form or another.

Yup, you can squeeze the balloon in in one place (ie. squeeze out 
semantics from request entities), but it'll bulge out somewhere else 
(ie. in the semantics encoded in the URI space).

At this point the choice between REST and the alternatives becomes more 
pragmatic and empirical. Given a particular distributed application, 
does it map naturally onto a REST architecture or onto something else? 
Do tools provide better support for the REST solution or something 
else? Is the REST programming model better understood by developers or 
are they more comfortable with something else?


Received on Friday, 10 January 2003 06:26:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC