REST is not specific interface or technology, but a style. The best example is the web itself - your browser sends an HTTP request to a web server, which responds with a web page.
Representational State Transfer in this context: The representation is the web page, the state is the information contained in it. We could change the representation by switching to serving up xml instead of html, but the information would be the same.
In a RESTful service, you use this style to send data objects back and forth - the state is transferred from the server to you, and then you send a new state back again.
So, in a sense, Tomcat will already do REST for you, if you put your server pages as resources: http://carsales.com/cars/porsche2149 could be the resource for your car, to which you could use HTTP POST or PUT to change the details of it.
The hallmarks of REST are using URIs to denote resources, as above, using JSON or XML as the interchange medium (although AHAH and other formats are used), and arguing about how to DELETE collections.
First, work out what your resources will be, and organise your URI system to fit it (use URL rewriting etc). Then determine the representation(s) you want to use. Finally, write the backend to deal with passing state representations around, and update the database.