Topic: REST and smarter user interfaces

All the recent buzz about REST is causing me to re-examine it.  I've been rather anti-REST in the past because it seems like it tends to promote very fine grained user-interfaces, where I tend to need to use more powerful UIs.

For instance, lets say you are making a reservation system for a vacation service.  You're likely to have to collect information on the people attending, if they want their meals included in the package, or if they want more flexibility to eat on their own.  You'll need to collect information on all the little side "excursions" or various other extra cost items.

Now you could have a ton of page views for all of this and make it RESTful, but that would be rather un-friendly.  You could have a plethora of forms on each page (so that each form is still interacting the the appropriate REST controller), but that's still a little unfriendly -- if people fill out the whole page and don't realize that you have to submit each item separately, etc

If you have a single more sophisticated form, the action handling it is going to have to break apart the request and chain it through many other controllers:action pairs, which seems workable on the surface, but it doesn't look like actions are designed to really chain that way.

Of course its highly likely that even with the more involved form there might be a need for the more simple REST controllers/views for tweaking things after the initial (wizard-like) creation.

Has anyone else starting exploring how REST and UI interact and can offer some advice?

Thanks

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: REST and smarter user interfaces

REST is great, but I don't think it's a solution to every problem. It seems especially difficult to apply to complex forms/relationships (like a Reservation in your example). Actually, multi-page forms seem especially difficult to do in Rails in general (e.g. validation). You can sometimes overcome this with AJAX, but that isn't always an option.

I think it's perfectly fine to have a controller handle multiple models. It may not be completely RESTful, but you are right, trying to shoe-horn a complex form into a RESTful design can get ugly - even worse, it can degrade the user experience.

I would suggest considering the REST approach first for every situation. If you can't see a simple RESTful solution, try a non-RESTful approach. I think that's what DHH was saying in his keynote. Giving a little extra thought to the REST approach can sometimes reveal problems, and solutions, in the design. But, if it doesn't seem to fit, no big deal. Use it where it works.

Railscasts - Free Ruby on Rails Screencasts

Re: REST and smarter user interfaces

I think the last post is the best advice.  Use things where they make sense and where they don't make sense, don't use them.  People often find one thing that does, say 90% of what you want to do really well.  They then agnonize over trying to make a tool do something it is not designed to do for the other 10% when they could just use something else that is more natural to the task. 

Rails, IMHO, is a perfect example of this.  It does web apps extremely well and makes them a "joy."  But it is domain specific.  People are touting Java vs. Rails all the time.  Since I develop in both, I would say for web apps where I control the database, Rails is a no-brainer.  It's excellent.  However, that leaves plenty of other types of applications where Java makes sense and is the right tool (although I'm still leary of J2EE). 

The trick is to find the right tool for the job.  People get really excited about their new hammer and then think everything is a nail.  If it's a bolt, use something else.  Sorry for the rant, but I just see people put themselves through too much pain sometimes trying to make something fit that doesn't, or they cannot see that different technologies can do different things well.  Or, because a tool does 95% of what you need in an incredible way, they miss out on that because it can't do the last 5% instead of leveraging it and then handling the 5% exceptions in a more appropriate way.

Re: REST and smarter user interfaces

I've often heard this 90/10 rule touted as one of the strengths of Ruby and of Rails.  They both highly encourage you to do things one way, but they allow you the freedom to ignore their preferences.  Java, on the other hand, gives you plenty of flexibility - until you run into a wall :-)

Re: REST and smarter user interfaces

The funny, or sad, thing about Java is that everybody knows things are too complex, so everybody is inventing framework x to solve the complexity that framework y didn't solve.  It makes it very frustrating to try to do much with it.  I just use it for system daemons, and various server processes that do various background things where C++ would be more painful and error prone (for me at least).  However, as much Java as I've done I have zero desire to do a web app in it and have so far successfully dodged J2EE :^).  Having done Java and some .NET, the funny thing is that .NET is pitched as just click here and there and we'll do everything for you so you get a lot of apps with very little application design.  Java on the over hand gets overdesigned and I have to trace x number of interfaces and factories to have to figure out what is going on.  The first time I had to do that was when I learned the evils of over-engineering and code generation combined at once!

Re: REST and smarter user interfaces

Ajax can be used to solve (some of) these problems. I'll use a simpler example, but I think you can use the same method for your application.

You want to create a blog: Posts and Tags. On the "submit new post"-page you want to be able to add new tags because you might need new tags for the post you're posting. You can create a "new tag" text field and a "create tag" button. If you click the button the tag will get added with an Ajax request. This request will be sent to the tags controller, so it's still REST, but it's also easy to use.

I hope this helped you.

Jules

Re: REST and smarter user interfaces

jules wrote:

Ajax can be used to solve (some of) these problems.

Ajax should never be used as a crutch for poor design. Make your app work without Javascript, then Hijax it if you feel the need.

I thought about how mothers feed their babies with tiny little spoons and forks, so I wondered what do Chinese mothers use. Toothpicks?

Re: REST and smarter user interfaces

jed.hurt wrote:
jules wrote:

Ajax can be used to solve (some of) these problems.

Ajax should never be used as a crutch for poor design. Make your app work without Javascript, then Hijax it if you feel the need.

Why is this design poor? Show a better solution.

Re: REST and smarter user interfaces

jed.hurt wrote:

Ajax should never be used as a crutch for poor design. Make your app work without Javascript, then Hijax it if you feel the need.

I don't believe this to be an example of poor design. Javascript has commonly been described as adding a behavioural level to a web app. If we take this definition then the way of interacting with the above app would not be broken by design, rather the AJAX routines would provide a useful usability shortcut to the non-AJAX way of operating the same app, which would be something like:-

1. Go to the 'Tags' screen
2. Create any new tags needed for the upcoming post
3. Go to the 'Post' screen
4. Create Post, adding tags from a series of checkboxes
5. Save Post

Perhaps I am missing something in your argument, but I don't understand why AJAX-ing the above procedure so everything can be done from one screen is a bad design descision? Is it not simply a way of making the user's experience quicker and simpler by providing a behavioural overlay to an already functioning application?

Surely this strategy is the preferred method of dealing with complex forms that reference a number of distinct RESTful model/controllers?  If NOT, then how are we supposed to unify RESTful principles with real-world, complex data input? Ideas?

Re: REST and smarter user interfaces

Surely this strategy is the preferred method of dealing with complex forms that reference a number of distinct RESTful model/controllers?  If NOT, then how are we supposed to unify RESTful principles with real-world, complex data input? Ideas?

I think it's good to create a RESTful base for your application. On top of that, you can create a user interface, somewhat like a separate application on top of the REST base. This Ajax page is that separate application/front-end.

Your application will have this structure:

front end 1 | front end 2 | ...
===============================
        REST interface

The REST part deals with things like data validation, and the front ends create a human useable application on top of that.

Would this work?