RE: [rest-discuss] RFC for REST?
>> To the extent that such a document is possible for an architecturalstyle, that document is my dissertation.
The problem is your PhD requires someone to have a PhD to understand it. Of
course I exaggerate, but I don't think you can understand what it's like not
being able to understand what the heck your disseration is saying without
weeks of studying just the part about REST. 99% of people aren't going to
>> The only way that REST changes over time...I didn't say anything about it changing over time. I instead was saying that
it is not very approachable for the average developer.
>> In regards to "untold hours wasted in debate", ... It is almost neverwasted, even when it is poorly informed.
Time debating is almost always wasted when it could have been avoided by
other more efficient means.
>> Expecting "workaday developer teams" to quickly understand REST, nomatter how carefully it is described, is just beyond reasonable
I completely disagree with you, respectfully. I think it is possible for
people to understand it, if presented in an easier to consume fashion. It's
not rocket science, after all, it's just currently made to seem that way.
>> No, at best all you will get is...So that would by requirement happen if you reviewed it?
FYI, I was a programming instructor for seven years, I developed all my
training materials during those seven years, and also I attended numerous
courses on how to teach. I also wrote a 1000 page programming book and
working in conjunction with a developmental editor from whom I learned a ton
about how to present information in an understandable manner. I know a
little bit about the subject of how to present information in an
From: Roy T. Fielding [mailto:fielding@...]
Sent: Tuesday, November 07, 2006 1:57 PM
To: Mike Schinkel
Cc: REST Discuss
Subject: 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 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
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
> 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
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.
- >> 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.