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

RE: REST made more concrete

• To: "'Mike Champion'" <mc@x...>, xml-dev@l...
• Subject: RE: REST made more concrete
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Tue, 19 Feb 2002 12:54:16 -0800

> From: Mike Champion [mailto:mc@x...]

<snip/>

> I found the recent discussion on the REST discussion list very
> helpful in understanding how REST-ful web services could
> work.  See Paul Prescod's sketch of a WSDL-ish spec for
> REST-ful specification of a web service
> http://groups.yahoo.com/group/rest-discuss/message/725
> 
> and a very interesting post later in the thread analyzing how
> a purchase order approval application might be specified in REST terms
> http://groups.yahoo.com/group/rest-discuss/message/734
> 
> This definitely helped me wrap my head around how one would
> actually use this in practice.

I recently worked through some thought exercises trying to relate REST to
the sorts of models I've used in the past building business applications
(looking more at the implementation side of things than the protocol side of
things). To some degree, REST seems to offer a real opportunity for tools
vendors. A very typical approach in web development is to have a number of
components (EJBs or COM components, for instance) that handle the actual
business processing of an application, but to rely upon name/value pairs
attached to a session object (correlated with the client via a cookie) to
track the components in use. I've always hated this approach -- not because
it violates REST, but because it does a lousy job of solving the problems it
is supposed to solve for me. Allowing the client to reference resources
rather than simply a "session", and associating state with individual
resources seems like it could offer a richer model for developers to work
with in developing web applications.

It also seems to me that a tool or framework geared toward this approach
could benefit from the sort of archetypes used in EJB applications. For
instance, EJBs are broadly classified into 3 types: StatelessSessionBeans,
StatefulSessionBeans, and EntityBeans. The EJB APIs deliberately obscure
these distinctions, but with REST these distinctions should be explicit. A
common pattern in EJB applications is to have a client always interact with
SessionBeans and not manipulate EntityBeans directly. In a REST-ful
application, you would want an abstraction visible to clients that looks
like a mutable resource (one that could be altered via a PUT). 

So I'm thinking that a REST-ful web development framework would have similar
archetypes for resources -- abstractions defining the interaction points
with a client, each uniquely identified by a URI. There would be three
categories of resources -- immutable resources (stateless services that
always looks the same), transient resources (typically created by an
immutable resource as part of a workflow -- the URIs referencing such a
resource will expire once the workflow is complete, or the referenced
resource is otherwise no longer valid), and mutable/persistent resources
(whose state can be altered via a PUT). The framework would have facilities
for easily managing the lifecycle of the resource components and the URIs
associated with them (as well as generating unique URIs for transient
resources). Alternatively, it may make sense to use two orthogonal
characteristics: mutable/immutable, and transient/persistent.

I'm still absorbing REST, so I hope I'm interpreting things correctly. But
if so, it seems to me that a framework along these lines could be a great
aid to developers. It could also help broaden mindshare for REST by
providing a framework that offers real value to developers -- namely a
better way for modeling complex applications than that promoted by
session-based toolkits.

• Prev by Date: Re: Errors in Kendall Clark's xml.com article on QNames
• Next by Date: RE: Traditional RPC
• Previous by thread: REST made more concrete
• Next by thread: RE: REST made more concrete
• Index(es):
  • Date
  • Thread