Re: Working Group Last Call on the HTTPbis document set

On Apr 29, 2013, at 7:31 PM, Jonathan A Rees wrote:

> Overall the new spec puts a heavy REST layer on top of HTTP that was not present in 2616. (Of course, since 2616 predates REST.)

Representation was used to describe the thing we called variants
in 2616, long before any other term -- it even predated the IETF
efforts in 1994.  You can see it used liberally (and somewhat
confusingly) throughout the first draft that Henrik and I created
in November 1994, as well as in the earlier descriptions of
content negotiation from TimBL.

  http://tools.ietf.org/html/draft-fielding-http-spec-00

REST (the model of how Web applications work) was originally
called the HTTP object model, which is something I developed
during that 94-95 time period while bouncing ideas back and forth
with Henrik.  It was my virtual test oracle.

I changed the name of the model to REST in 1997, after
diving into research on software architecture and architectural
styles for my dissertation topic.  I gave several talks with
Representational State Transfer as the title in early 1998,
including a recruiting talk in May 1998 at Microsoft Research.

  http://roy.gbiv.com/talks/webarch_9805/index.htm

So, no, RFC2616 does not predate REST, by any stretch of the
imagination.  The reason the terms differ in 2616 is because
there was a disagreement among the seven editors about whether
to use my terminology (entity/representation/resource) or
Jeff Mogul's terminology (instance/variant/resource). That
particular bike-shed did not turn out well, and the result was
an RFC with mixed terminology and not much review.

Since the purpose of this revision of the standard is primarily
to fix the editorial inconsistencies and unclear text in 2616,
it should be no surprise that we chose a consistent set of terms.
Furthermore, since I am the one doing the bulk of the writing,
it is natural that I would prefer a set of terms that is
consistent with the rest of my writing (pun intended).

> An uninitiated reader might take the REST theory to be normative, but I don't see how it can be, given that the deployed base certainly doesn't conform to it. I'm sure the spec will provide lots of yummy new fodder for spec-lawyering in the years to come.

REST is an architectural style.  HTTP is not in the least
bit bound to follow it, though it won't work as well with
other styles.  Using the same terminology, however, makes it
possible to explain things about HTTP that simply aren't
possible to explain using other models.  The REST terms
were chosen for that purpose, and some of the design
rationale given in the document is (naturally) based on
the lessons learned from applying REST.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>