[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: REST has too many verbs


rest interface order
Alaric Snell wrote:
> 
> .... I'm certainly of the opinion that REST is handy for idempotent
> thing-fetching, like DNS and browsing information, but it'd be nice to be
> able to suddenly open up a session with a resource and use server-side state
> when it's sensible to do so!

REST is totally hip with server side state. *BUT* it says that servers
and clients should not hide state from each other. If you send me a
purchase order then we don't just hide that in a database and refer to
it through magic cookies. Rather, I return you a URI for the purchase
order and now you have access to it whenever you need it. So the state
is *explicit* and addressed through URIs.

> That's my main bugbear with "HTTP for everything"; I'd like a protocol that
> handles REST as one particular case.
> 
> I'm working on a model for this under the name of Mercury (I have a periodic
> table fetish); the idea is quite simple at heart. A network-accessible object
> exposes a set of Interfaces, named with something unique like a URI; each
> Interface is a set of Methods (Are we object-oriented yet, kids?) with simple
> string names unique within that Interface (I won't say namespace out loud,
> but I'm thinking it).

If you start having many of these interfaces, web service combination
becomes much more difficult. At the very least, if you want the benefits
of REST, every single interface should have a GET method.

>....
> Sorry, getting stuck in the details again. To summarise, I think it's...
> wrong that we have the current approach to designing protocols; we have TCP
> and UDP and RDP and so on, all with their own session establishment protocols
> and port numbering schemes, then SMTP and HTTP and NNTP and so on, all with
> their own *addressing* schemes and data models.

I agree. HTTP's addressing scheme and data model is clearly a superset
of SMTP and NTTP so it's pretty clear what I'd do about that. I'm
somewhat open to your idea of trying to integrate different kind of
session establishment protocols but I really don't need unreliable
delivery for anything I do so I wouldn't want to pay a very high cost in
complexity for support for it. YMMV.

 Paul Prescod

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.