Loosely Coupled

In my last post, I described I was implementing a SOAP web service controller between my Ruby chat bot and a CORBA component my company is developing. The WDSL for this service was straightforward, and with help from the Eclipse Web Service wizard, it was complete in no time. I had some downtime before the CORBA module I needed to connect with was complete, so I began to look into re-implementing my controller as a REST web service. A little digging led me to Restlet . Restlet is a lightweight framework for developing REST web services in Java. I've seldom had an easier time integrating a new Java package and getting something up and running. Restlet comes bundled with it's own HTTP server, but I opted to deploy a WAR file to our existing Tomcat installation. There are three basic steps needed to get this to work. Creating a Resource is the first step. The Resource is the brains of your service. It captures request parameters (from the URL or encoded in the body), the...

I'm still struggling with the decision to create a REST or traditional web service. Over the weekend I started reading RESTful Web Services and I'm now thinking that a RESTful approach is very doable. Here are my thoughts: REST resources are inherently stateless and shareable. All the information needed to reconstruct the view of a resource exists in the URI. Although I listed this a a "pro" before reading the book, I'm more convinced of the benefits now. I had a concern about long query criteria in the URI, but I'm thinking of adopting the Ruby-like approach of referring to ids. The RESTful authors prefer a more human readable URI (as it is self documenting), but many of my filter criteria cannot be accessed through unique strings. I believe I was trying to do too much at the beginning (not keeping it simple). My object relationships are complex, with most objects linked to several related (non-subordinate) lists of objects. I wanted to have a sin...

Now that the models are complete, I want to expose access to them as a web service. I'm thinking REST is the way to go. A RESTful approach seems simple. It appears to solve pesky "back button" problems and session timeout issues, but I have one big question: How to fit all the information I need into the URL? The application I'm working on has A LOT of data. The main objective of the application is to allow filtering of this data down to a useful, manageable set. It wouldn't be uncommon for a user to ask for something like: Give me everything connected to Item1, Item2 and Item3, Hide anything that has to do with Item4 or Item5 In addition, give me anything that mentions Items 6, 7, or 8 and is new to the system in the past month. To put all this information in the URL is a scary proposition. In it's previous life as a Java web application, all this search criteria was built incrementally and stored in a user's session. Since the client ...