|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: REST has too many verbs
Joe English wrote: > >... > > > 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. No, it isn't part of a session/presentation-layer. It is an application protocol where the application is the Web, where the Web is defined to be: "the universe of network-accessible information, the embodiment of human knowledge." -- which of course includes purchase orders and widgets-for-sale. Enough hand waving. What does this mean concretely? The Web has an addressing model and a way of giving state addresses. I think this is what makes it an application protocol. BEEP explicitly chooses not to have an addressing model which makes it a point-to-point session layer, and cannot be used as a coordination language. Personally, I think that in this day and age there is an obvious choice for an addressing model but... >... > 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. I've seen some pretty good instant messaging systems built on HTTP but you need to tunnel it over an existing connection layer to avoid TCP setup costs. BEEP would be a good session protocol if firewall admins allow it. >... > IOW: HTTP is good when a typical session consists of a single > POST or GET; BEEP is good when sessions get more complicated. The word session is somewhat ambiguous. BEEP is good when a typical *TCP session* consists of more than a single GET or POST. If you wanted to scale BEEP up to a transaction that lasted several days over network outages then I think you'd run into big problems. Without a standard addressing model there is nowhere to "put" data that needs to survive longer than the session. You'd need to add that sort of feature at the application layer, I think. With HTTP you would typically store a session ID in the URI and it survives until one side or the other deletes it, no matter what happens on the network. Paul Prescod
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








