Re: REST has too many verbs
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!
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