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

RE: [rest-discuss] RFC for REST?

Expand Messages
  • Mike Schinkel
    ... style, 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
    Message 1 of 58 , Nov 7, 2006
    • 0 Attachment
      >> To the extent that such a document is possible for an architectural
      style, 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
      do that.

      >> 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 never
      wasted, 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, no
      matter how carefully it is described, is just beyond reasonable
      expectations.

      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
      understandable manner.

      -Mike Schinkel
      http://www.mikeschinkel.com/blogs/
      http://www.welldesignedurls.org/




      -----Original Message-----
      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
      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
      • 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.