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
