Web: interactive, REST: batch?

I've written a web application that my company is using internally for transferring files. It's sort of like an ftp site, but with user accounts, projects and automatic removal of stale files. It's called File Exchange Server, or FES (fez).

I designed it from scratch to be able to be bilingual; it can operate either as a web application and output HTML/CSS, or work as a REST application and provide 'just the facts'. Because of time pressures, I got the web side working fine and rushed it into Production where it's working very well. Now it's time for me to go back and get the REST side working again.

I have a suite of tests that exercises both the web side and the REST side. The REST application test is failing almost immediately because of a page FES jumps to right after log-in that warns the user that some of their files are stale and need attention. There's no equivalent page on the REST side, but this raises an important issue (after three paragraphs, I hope so).

Should the RESTful interface behave exactly like the web interface to an application?

I think the answer is no -- REST is there just to get the facts. The web interface can do anything, because there's a human on the other end. But we're going to be using FES in an automated system, and the automated system wants to get in and get out with a minimum of fuss. It doesn't care about anything that's not relevant to the job at hand, which is a) log in, b) get that file that I came for, and c) log out.

Thoughts?

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Update: Correct minor typo.

Comment on Web: interactive, REST: batch?

Replies are listed 'Best First'.
Re: Web: interactive, REST: batch? by holli (Abbot) on Dec 20, 2007 at 20:56 UTC
Well, the baby is already down the river, but imho you shouldnt have implemented the "web application" at all. I'm currently at a similar project and can tell you it's virtually impossible to keep the web app part and the REST part (for those who dont know, REST is basically a datacentric approach to AJAX) in sync. In the end it led to a complete rewrite, abandoning the web app and moving the control flow/logic to the client side (using the ExtJS framework). As for your question, no the REST part should not act like the web app. holli, /regexed monk/	[reply]
Re^2: Web: interactive, REST: batch? by talexb (Chancellor) on Dec 20, 2007 at 21:06 UTC
I'm currently at a similar project and can tell you it's virtually impossible to keep the web app part and the REST part (for those who dont know, REST is basically a datacentric approach to AJAX) in sync. I must not have explained myself very well -- the web part and the REST part run from the same Perl code, they just output using different TT2 directories. It's impossible for them to be out of sync, unless you count the 'race condition' where two files arrive via REST and a user gets a web page generated after just one of the files has arrived and worries that the other file is missing. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^3: Web: interactive, REST: batch? by dsheroh (Monsignor) on Dec 21, 2007 at 18:40 UTC
This is basically the approach that I would take as well, so I think you're at least on the right track. For the specific point that you're asking about, it sounds like the "there are stale files" page is essentially just a click-through warning, is it not? (It may also contain links to do something about the cause of the warning, etc., but I'm talking about its core function/nature.) If that is the case, then it's not essential to the app and it has a sensible default exit behaviour (i.e., "user clicks OK and continues on to the same page they would have gotten if there weren't stale files"). I would, therefore, have application check to see whether the corresponding template exists and, if not, just skip over the page and jump straight to the default exit behaviour. For the REST interface, then, you just delete the template for that page and it will skip over the warning. Later on, this also allows you to easily remove the warning from the interactive interface (delete the template) or add the warning to the REST interface (create a template) as requirements change, all without requiring the application to know (or care) which interface is being used, just which template directory to use.	[reply]
Re: Web: interactive, REST: batch? by ysth (Canon) on Dec 21, 2007 at 00:31 UTC
If REST is there to just get the facts, is the staleness and needing attention a fact or not? It really depends how you intent the REST interface to be used. If you should be able to build a non-web client app using it that more or less looks just like the client app, then the login result should return that info. I'm a little dubious about the whole concept of sharing a controller between views. Seems like all too often you are going to run into situations like this. Which is not to say controller and view shouldn't be separated! Just that the benefit of that separation is something other than reusability of the controller. -- CollegeGear.com - more than just college gear (though, yes, we have college-branded teddy bears)	[reply]
Re^2: Web: interactive, REST: batch? by talexb (Chancellor) on Dec 21, 2007 at 02:48 UTC
I'm a little dubious about the whole concept of sharing a controller between views. Seems like all too often you are going to run into situations like this. Which is not to say controller and view shouldn't be separated! Just that the benefit of that separation is something other than reusability of the controller. Mmm. It seemed to make sense to me to have the application share everything, and just output different stuff based on which template (web or REST) that it was using. But you raise a very good point -- now I'll (presumably) have to change the behaviour of the application based on which mode I'm in, and that's something I was trying to handle completely using templates. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^3: Web: interactive, REST: batch? by ysth (Canon) on Dec 21, 2007 at 03:23 UTC
It seemed to make sense to me to have the application share everything But the REST interface isn't an application. I suspect you could just return whatever data is needed about the stale files, whichever template is used. -- CollegeGear.com - more than just college gear (though, yes, we have college-branded teddy bears)	[reply]
Re: Web: interactive, REST: batch? by polettix (Vicar) on Dec 21, 2007 at 01:23 UTC
Unless heavy AI is involved, an automated program should be something designed to do some specific jobs. Where "job" can range to the simple scenario you talked about ("get in, grab and run away") or perform complicated operations like cleanups based on various criteria (e.g. stale stuff that's been ignored for more than some time should be...). So, I don't see any reason why a REST interface for automation should have less power than the interactive one. On the other hand, it has to be considered that the interaction model is more or less "pull" with REST, and somewhat "push" with the interactive one. When you notify the user about stale stuff, you're "pushing" information, requesting for attention. This isn't probably the case for REST, where you would better provide means for questions to be asked (like "is there any stale stuff?"). Hey! Up to Dec 16, 2007 I was named frodo72, take note of the change! Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Io ho capito... ma tu che hai detto?	[reply]
Re: Web: interactive, REST: batch? by Cop (Initiate) on Dec 20, 2007 at 21:09 UTC
Sounds like you had a messy design. Further seperate your web service layer and client web page layer should be really helpful (seperate C M V). With a better design, your web page generator shouldn't care the underlying web service, at least not much.	[reply]