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

RE: REST made more concrete

• To: "'ldodds@i...'" <ldodds@i...>, Michael Brennan <Michael_Brennan@A...>
• Subject: RE: REST made more concrete
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Tue, 19 Feb 2002 14:00:14 -0800
• Cc: mc@x..., xml-dev <xml-dev@l...>

> From: Leigh Dodds [mailto:ldodds@i...]

<snip/>

> In particular I think I think that a good worked example would be to
> take the canonical "Java Pet Store" example used in the Sun Blueprints
> and show how it can be made RESTful. Do you think thats something
> worth working through?

That sounds like it could be useful.

> To start things off, I've been assuming that being RESTful would imply
> changes to the presentation layer only. The business logic remains
> untouched.

I would agree. However, I think some additional abstractions would probably
be necessary beyond the EJBObject interface. In some cases, a REST resource
might map onto an EJBObject in a 1:1 fashion. I think there will be cases,
though, where it is not that straightforward. For instance, a mutable
resource might actually rely upon a StatelessSessionBean (which relies upon
state encapsulated in the resource, and which may internally manipulate one
or more EntityBeans) for the actual processing. I think you'd probably want
one central dispatcher that is tied to a particular URL or set of URLs.
Additional relative paths can be tacked onto that URL to reference
particular resources. These resources would be actual components managed by
the dispatcher in a fashion similar to how app servers manage EJBs. The
dispatcher would use the full URL to identify the resource being addressed,
rather than using criteria in a POST-ed message for this (which is the
common case in current web apps).

Alternatively, some resources might be modeled directly by an independent
servlet or JSP. But it seems to me that this would not work for transient
resources. You would need a central dispatcher/manager for transient
resources, and these transient resources would typically be very lightweight
components intended to manage one portion of a workflow.

• Prev by Date: Re: REST made more concrete
• Next by Date: RE: REST made more concrete
• Previous by thread: Re: REST made more concrete
• Next by thread: RE: REST made more concrete
• Index(es):
  • Date
  • Thread