Lists Home |
Date Index |
Gavin Thomas Nicol wrote:
> >Still, the cost/benefit of inventing ANOTHER REST protocol
> >would probably not pan out, especially considering how extensible HTTP
> Have you considered doing so? Seems to me that BEEP would do rather
> well as part of an implementation of the REST architecture...
> certainly no worse than HTTP.
Roy claims he spent five years, working full-time at the W3C, tuning
REST and HTTP: "The first edition of REST was developed between October
1994 and August 1995, primarily as a means for communicating Web
concepts as we wrote the HTTP/1.0 specification and the initial HTTP/1.1
proposal. It was iteratively improved over the next five years and
applied to various revisions and extensions of the Web protocol
standards. REST was originally referred to as the “HTTP object model,”
but that name would often lead to misinterpretation of it as the
implementation model of an HTTP server."
By all accounts, Roy Fielding has several advantages over me, in that he
is smarter, worked for the W3C, was an implementor of Apache and
lib-www. I have a job wherein I get paid for solving problems, not
designing architecture. But if you and Simon want to re-invent the wheel
then you are welcome to start with HTTP and then continue with XML and
then after that consider TCP and IP.
I see nothing in BEEP that indicates that has built upon those years of
work. It doesn't even claim to be a protocol at the same level of the
protocol stack as HTTP. You'd have to start from scratch on top of it.
As far as I can see, BEEP is a connection oriented protocol which means
the first thing you'll have to do is figure out a connection-less
profile and reinvent connection-less session state. AFAICS BEEP has no
notion of resources or representations of them. It consciously and
explicitly leaves out URIs, which are the core of the REST model. etc.
etc. BEEP looks like an interesting bit of engineering but it would be a
MAJOR effort to rebuild a REST-oriented application protocol on top of