Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] RFC for REST?

Expand Messages
  • Roy T. Fielding
    ... 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
    Message 1 of 58 , Nov 7, 2006
    View Source
    • 0 Attachment
      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
    • Mike Schinkel
      ... Well, there are clearly issues, but I plan to try. I ll get back to the list on it. -Mike Schinkel http://www.mikeschinkel.com/blogs/
      Message 58 of 58 , Nov 8, 2006
      View Source
      • 0 Attachment
        >> 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.
         
         


        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?

        Hi Mike,

        On Nov 7, 2006, at 8:52 PM, Mike Schinkel wrote:
        Which means, unless we make it easy for these occupational programmers,
        power users, and entreprenuers to both 1.) understand REST and 2.) implement
        REST they are going to butcher the hell out of it, and your wonderful
        architectural design will become invisible to all the things that call
        themselves REST that, according to you (Roy) are not.

        So I'm actually trying to help you all to head off this bastardization of
        REST before the Mashup crowd obliterates it because, after spending time
        learning it, I see that it has a lot of true value. Capisce?

        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.

      Your message has been successfully submitted and would be delivered to recipients shortly.