Lists Home |
Date Index |
At 02:17 PM 4/07/2002, Rich Salz wrote:
>>Firstly REST did not come *after* the fact as you state.
>I was on the HTTP WG for a bit. I don't ever recall any "guiding
>architectural principles" being emphasized. It was all being made up as
>we went along, with occasional number-crunching (cf Mogul's 95SIGCOMM
>paper) the notable exception.
>Now, this is not to say that such things DIDN'T happen, just that I don't
>remember them during my (incomplete) tenure on the mailing list.
>It certainly could have happened
To be more accurate I should have said 'REST did not come solely *after*
the fact as you appear to be implying'.
I was responding to your assertion that the 'REST camp' is based on a
logical fallacy - 'Post hoc propter hoc' i.e. "after the fact, therefore
because of the fact".
Perhaps we/you need some independent confirmation that it did indeed happen
and then we/you can accept Mr Fielding's statements as fact.
>Hm. Thie following search result from Google is a bit curious, then:
> Your search - state transfer fielding representational
> site:ftp.ics.uci.edu - did not match any documents.
And so it is proven that the 'REST camp' has indeed no basis, with the
great Google god not acknowledging the existence of any relevant facts:-)
PS From where I sit, I don't care if REST came before, during or after. I
want to be able to develop loosely coupled systems based on simple
principles that will scale up, as and when required, making the best use of
existing as well as new infrastructures and technologies. I don't want
vendor lock-in, I don't want to do RPC, I don't want to be installing s/w
on clients machines all over the place and I certainly don't want to
reinvent any wheels. If anyone can show me a better way than REST then
please do so (either privately or on rest-discuss as this is not really an
xml-dev topic, unless of course the 'magic pixie dust of xml' can solve my
problems as well!)