On May 7, 2007, at 12:16 PM, Steve Bjorg wrote:
>>> Most
>>> discussions on this list revolve around how to use http methods,
>>> status codes, and headers to map REST concepts into HTTP. While REST
>>> might be conceptually larger, it is bounded by its HTTP heritage.
>>
>> Bounded? No way. It isn't even 1/3rd of the style.
>
> Can you cite an example of what you mean?

Representational State Transfer. HTTP is only the transfer part.
URIs, media types, and hypertext as the engine of application state
have only incidental connections with HTTP (HTTP was created to do
that stuff more efficiently than the original attempts to do so using
FTP and Gopher, just as waka will do so more efficiently than HTTP).

> Ok, so here is my conundrum: I was invited to give a short
> presentation on REST following a presentation on SOAP (talk about
> the one-eyed guiding the blind! As a side point, I did refer them
> to you first :) ). Since I only have 20 minutes to convey of a few
> key points, I can either focus on the underlying richness of HTTP
> and how it can be tapped by applications (I think it would be a
> great service to web-service authors to introduce them to the magic
> of caching and simple redirects) or, if I stay true to the topic,
> talk about application architecture and distribution of state and
> stateless protocols. Either topic would probably be enlightening
> to many, but it's undeniably clear that the latter is what I need
> to convey to stay on topic.

The style can be explained in 5 minutes, with the remaining time spent
on your HTTP examples. Conference organizers are always going to be
clueless, for the same reason that the SOAP enthusiasts were clueless
when dealing with the comparison. They aren't interested in facts.

Alternatively, just start your talk with "I am going to talk about
web architecture as it exists today, not REST" and you will be fine.

> Is there a key message you focus on as the key take away for your
> talks on REST?

Engineer for serendipity.

....Roy