- From: Miles Sabin <miles@milessabin.com>
- Date: Fri, 10 Jan 2003 11:25:56 +0000
- To: www-ws-arch@w3.org
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? Cheers, Miles
Received on Friday, 10 January 2003 06:26:28 UTC