Hi Rob, Thankyou for the very sound advise. I know exactly what you are saying about having an object layer that communicates through a data access layer, to a persistant storage.
I think I agree, I will leave my restlet app to the side for now, and start to implement domain objects that can populate themselves from a MySql database by going through a simple data access layer. When I have that down, I could get the resources to instantiate internal domain objects based on IDs coming through the URI, and then issue the necessary update, delete and insert operations on those domain objects and classes (in the handle*() methods). The getRepresentation() method will generate Xml from the internal domain object when a GET is issued. :-D Cheers, Marcus. "Rob Heittman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On this last point (how to do the persistence layer), there are many ways to approach it. A good quote from Jerome: > no particular persistence technology is favored by the Restlet API. Here are > some possibilities for resources: > - object database (such as db4o)> - XML database (such as eXist)> - manual > JDBC calls> - EJB / JPA technology> - Hibernate (transparent ORM)> - iBatis > (manual ORM)> - Restlet JDBC/XML connector If your client is written by you, very intelligent and secure, you may want to submit SQL and receive result sets mapped to XML directly. But this means you must be very sure that the client can be trusted to send valid SQL, unless you introduce Filters or some other means of checking the SQL for sanity. There is an impedance mismatch at work here as well; SQL is not particularly resource-oriented, so figuring out a good way to map your SQL queries to a RESTful address space is challenging. For a public API or general interoperability, I try to expose an XML or JSON view of my database resources that is more aligned with application domain objects and less tied to the relational paradigm. This is easier to control and secure, easier for your API clients to comprehend, and more flexible when you want or need to change the backing data store. When doing this latter approach, my Resources in the Restlet paradigm provide the bridge between the HTTP address space (GET /person/rob) and the application object domain (new Person("rob")) -- these domain objects, in turn, use ORM, JDBC, etc. to deserialize their graph from the database -- which may involve complex joins, multiple queries, etc. To follow this pattern, your first job is to create an object layer (not Restlet dependent) using your choice of data access technologies. Since you are coming to this from a non-Java world, you probably don't have religion on this front. Hibernate is a popular choice, but I confess to not liking it much; it attempts to achieve "transparent and automatic persistence," something I've never approved of. I like my persistence explicit and manual. iBATIS is a lighter weight alternative that requires explicit invocation by the programmer, which I like much better. JDBC itself is not bad, but is hard for new users to code correctly -- handling failures properly, not leaking connections, etc. At least 70% of the time I use JDBC directly, with a couple trivial wrapper classes that help with the correctness. There are many sources on the Web to help you make these choices for your app -- and as Jerome said, Restlet is agnostic about your choice. Then, join this object layer to the RESTful world by writing Resources. You can also combine the steps above -- the Resource itself can be the application domain object -- but I have found the two-layer approach above to be much more workable in practice. - Rob
