Loosely Coupled

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

All my models are implemented in Rails and I wanted to give a quick update on how things are going. For now, I'm been using the rails views and controllers to test my code (automated tests coming soon). This has worked out great for me. Since my application only allows users to view and filter database records, I don't have a lot of validation checks, but I wanted to get a feel for the performance of pages need to display a lot of data from various tables. One page I tested performs 35 queries (including all the counts and show field commands) and takes about 5 seconds using the Webrick server (from NetBeans so I believe JRuby is being used). The development log lists the time spent in the database as less than 1 second. I'm sure performance could be better, but this is a big improvement over what we had before and the database I'm using contains more records. I'm still noticing that when you ":include" more than one model in a "find" comman

I was out last week, but finally got my schema in a Rails friendly format and the scaffolding utility is working great! I thought I'd hit on some of the pain points I experienced during this process and how I worked through them. MySql stinks when you need to change the schema of a database containing data. To make things easy, I've been working with an empty database and using the MySQL administrator to capture the SQL. The plan was to run this SQL against existing databases to upgrade them. This process doesn't work like I'd hoped. For some columns, the SQL query fails when I try to change a column name (like changing the primary key name to the Rails default 'id'). There are no foreign key constraints on this field and it does not fail on every table where the column name must change. I can't figure out why MySQL bombs on these specific statements. Maybe it's because these table have large row counts (~1M rows)??? Luckily, I won't be creat