[
Lists Home |
Date Index |
Thread Index
]
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
|
