On Nov 7, 2006, at 7:01 AM, Mike Schinkel wrote:
> I think that is one of the key problems with REST, and why so many
> urban
> legend have grown up to surround it. Without an authoritative
> document that
> explains REST in work-a-day developer terms in addition to the
> rigorous
> language required by such authoritative documents, untold hours are
> wasted
> in debate and by people simply trying to grok it all.
To the extent that such a document is possible for an architectural
style,
that document is my dissertation. Anyone who claims that REST is
something
other than what is in my dissertation is just babbling nonsense -- the
dissertation defined the term (and other people making it a buzzword
won't
change that). People are free to claim that there is more to
"web architecture" than what I included in REST, and that perhaps some
of that should have been included in REST, but REST itself is just a
name
chosen for a specific style that I defined as characteristic of the best
designed parts of the Web.
The only way that REST changes over time is in the sense that I
sometimes
need to expand on the terse explanations provided in the dissertation,
because I was in a hurry when I wrote it. In most cases, such expansion
is merely pointing people to other stuff I wrote ten years ago, or about
the entire topic of media type design which I left out because I ran out
of time. There are also other styles that build upon REST, but they are
*other styles*.
In regards to "untold hours wasted in debate", that is close to the goal
of my dissertation -- to introduce a way of thinking about software
architecture that promotes honest debate about the properties that are
desired and actual thought applied to the constraints chosen to achieve
them (and their resulting trade-offs). It is almost never wasted, even
when it is poorly informed.
Most people spend six months or so butting their preconceived notions
of what's "important" against the REST constraints before realizing the
benefits of REST. I am not surprised at all by that, since almost all
of the design behind REST is focused on applications that need to
survive for decades of independent evolution. We all know that our
software industry rarely sees beyond today's build. Expecting
"workaday developer teams" to quickly understand REST, no matter how
carefully it is described, is just beyond reasonable expectations.
> Publishing such a
> document as an RFC or the equivalent for the IETF, with significant
> examples
> would go a long way to avoid so much needless thrashing. Especially
> when you
> consider how passionate many people on this list are in their
> beliefs that
> strict adherence to the tenents of REST are essential.
>
> So I guess I'm calling the question! Can we create an RFC, or some
> other
> authoritative document that defines REST written in a language
> understandable by those not accustomed to reading and interpreting
> specifications?
No, at best all you will get is a committee that has some vague notion
of what they consider to be design to write down the least common
denominator of misinformed "best practice" based upon whatever Microsoft
chose to implement in its last release. The IETF has made a habit of
that recently.
I might write another book some day, assuming I ever get in the swing of
writing on a regular basis (and ignoring email). I doubt that I would
call it a REST book, though it would contain REST. I am sure the
publisher
would try to market it that way anyway.
....Roy
