OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] REST has too many verbs

[ Lists Home | Date Index | Thread Index ]

Paul Prescod wrote:

> I see nothing in BEEP that indicates that has built upon those years of
> work.

Well, it was designed by Marshall Rose based on his (considerable!)
experience with existing protocols as "kind of a 'best hits' album
of the tricks used by experienced application protocol designers
since the early 80's." [1]

> It doesn't even claim to be a protocol at the same level of the
> protocol stack as HTTP.

If you see HTTP as an application-layer protocol for displaying
Web pages, then no; if you see it as a session/presentation-layer
protocol for building Web services -- which AIUI is part of the REST
philosophy -- then it is.

> 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
> it.

Agreed.  BEEP is better for applications that require a more tightly
coupled ongoing dialogue between endpoints than what REST/HTTP
provides.  For instance BEEP would be a better foundation for an
instant messaging system than HTTP.  For applications that fit
naturally into the REST architecture (web-page fetching, print
spoolers, online purchasing, etc.,) HTTP would be a better choice.

IOW: HTTP is good when a typical session consists of a single
POST or GET;  BEEP is good when sessions get more complicated.

[1] <URL: http://beepcore.org/beepcore/about_qanda.jsp>

--Joe English



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS