Re: [rest-discuss] RFC for REST?
- 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 manyTo the extent that such a document is possible for an architectural
> legend have grown up to surround it. Without an authoritative
> document that
> explains REST in work-a-day developer terms in addition to the
> language required by such authoritative documents, untold hours are
> in debate and by people simply trying to grok it all.
that document is my dissertation. Anyone who claims that REST is
other than what is in my dissertation is just babbling nonsense -- the
dissertation defined the term (and other people making it a buzzword
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
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
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
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 aNo, at best all you will get is a committee that has some vague notion
> document as an RFC or the equivalent for the IETF, with significant
> 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
> authoritative document that defines REST written in a language
> understandable by those not accustomed to reading and interpreting
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
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
would try to market it that way anyway.
- >> I get it, and I agree. There needs to be a "REST for the REST of us." ...Well, there are clearly issues, but I plan to try. I'll get back to the list on it.Hi Mike,
From: Dr. Ernie Prabhakar [mailto:drernie@...]
Sent: Wednesday, November 08, 2006 9:23 AM
To: Mike Schinkel
Cc: 'REST Discuss'
Subject: Re: [rest-discuss] RFC for REST?On Nov 7, 2006, at 8:52 PM, Mike Schinkel wrote:I get it, and I agree. There needs to be a "REST for the REST of us." Obviously, we'd want those Ph.D.s who *do* understand REST at a deep level to vet it for accuracy, but I'd love to see something concise that captured the key points that the people doing the "engineering" could work from.The tricky questions are:a) Can you write something like that for a "general" audience, or does each subgroup need something tailored for its needs in order for it to make actionable sense?b) Can REST really be compressed to 1-3 pages without becoming a marketing brochure? :-)I don't know the answers -- which perhaps explains some of the skepticism you received -- but I for one think any attempt to move in that direction would be worthwhile.Good luck!-- Ernie P.