[Catalyst] using REST within the app

[stephen joseph butler]

On 5/24/07, John Goulah <jgoulah at gmail.com> wrote:
> What are some of the patterns people are using to implement this?  Any other
> thoughts?

People are going to hate me for saying this... but I've started to
adopt the Java bean paradigm for my Catalyst app. To the point where I
even have a whole MyApp::Bean hierarchy (skip to the bottom if you're
already gearing up for a big paradigm fight).

Why? I had this nice little CRUD app that did what I wanted. But then
I started looking at adding XMLRPC support, and other things.
Reviewing my code, I realized I couldn't just call my existing methods
because they all assumed things like:

1) Parameters would come in an HTML::Widget or some CGI like interface
(param, params, parameters, etc). When dealing with XMLRPC this isn't
true.

2) Errors would just be stuffed into the stash. Which is fine if
you're going to render them, but isn't as nice for other solutions.
Suppose I needed to add SOAP support later. Errors should come via
SOAP exceptions.

3) That the context would be able to provide things like the current
user. With XMLRPC, sometimes the external app would need to feed the
user to my backend, so what's in the context would be wrong.

4) The general assumption that the content in the stash was going to
be rendered. Some methods would fetch several things from the database
and stash them because that's what the templates would need. But with
XMLRPC, it was a waste.

I happen to have done some work with JavaEE and am familiar with the
design pattern, so that's the solution I reached for. It's still MVC,
but the controller has two parts.

A) The servlet, which corresponds to Catalyst controllers. But the
servlets don't do any of the actual work; they just marshal the data
between the HTTP interface and your beans...

B) The beans, which contain all the business logic. These interact
with the model, manipulate it, and then return the results to the
servlets. Beans should never be written with the transport (HTTP,
SOAP, XMLRPC) or view in mind: all that's the job of the servlet. If
the view needs extra data from the model for this transport, then it's
the job of the servlet to fetch that.

This might or might not work for you. I'm not interested in starting a
design paradigm war; I understand they all have their own strengths
and weaknesses. Just thought I'd throw this out there.