Are there any MVC web frameworks that support multiple request types?

Question

In every MVC framework I've tried (Rails, Merb, Waves, Spring, and Struts), the idea of a Request (and Response) is tied to the HTTP notion of a Request. That is, even if there is an AbstractRequest that is a superclass of Request, the AbstractRequest has things like headers, request method (GET, POST, etc.), and all of the other things tied to HTTP.

I'd like to support a request-response cycle over SMS, Twitter, email, or any other medium for which I can make an adapter. Is there a framework that does this particularly well?

The only other option I've thought of is creating, for example, a Twitter poller that runs in a separate thread and translates messages into local HTTP requests, then sends the responses back out.

If there were a good framework for multiple request media, what would routing look like? In Rails, the HTTP routing looks something like:

map.connect 'some/path/with/:parameter_1/:paramter_2', :controller => 'foo', :action => 'bar'

How would a Twitter or SMS route look? Regular expressions to match keywords and parameters?

Answer 1

I haven't seen one. The issue is that the request is also tied to the host, and the response is tied to the request.

So if you get a request in via email, and a controller says to render view "aboutus", you'd need the MVC framework to know how to :

• get the request in the first place - the MVC framework would almost need to be a host (IIS doesn't get notified on new emails, so how does your email polling code get fired?)
• allow flexible route matching - matching by path/url wouldn't work for all, so request-specific controller routing would be needed
• use the aboutus email view rather than the SMS or HTTP view named "aboutus"
• send the response out via email, to the correct recipient

A web MVC framework isn't going to cut it - you'll need a MVC "host" that can handle activation through web, sms, email, whatever.

Answer 2

You seem to be working mostly with Java and/or Ruby, so forgive me that this answer is based on Perl :-).

I'm very fond of the Catalyst MVC Framework (http://www.catalystframework.org/). It delegates the actual mapping of requests (in the general, generic sense) to code via engines. Granted, all the engine classes are currently based on HTTP, but I have toyed with the idea of trying to write an engine class that wasn't based on HTTP (or was perhaps tied to something like Twitter, but was separated from the HTTP interactions that Twitter uses). At the very least, I'm convinced it can be done, even if I haven't gotten around to trying it yet.

Answer 3

You could implement a REST-based Adapter over your website, which replaces the templates and redirects according to the input parameters.

All requestes coming in on api.yourhost.com will be handled by the REST based adapter.

This adapter would allow to call your website programmatically and have the result in a parseable format.

Practically this means: It replaces the Templates with an own Template Engine, on which this things happen:

• instead of the assigned template, a generic xml/json template is called, which just outputs a xml that contains all template vars

then you can make your Twitter Poller, SMS Gateway or even call it from Javascript.

Answer 4

The Java Servlet specification was designed for Servlets to be protocol neutral, and to be extended in a protocol-specific way - HttpServlet being a protocol-specific Servlet extension. I always imagined that Sun, or other third poarty framework providers, would come up with other protocol-specific extensions like FtpServlet or MailServlet, or in this case SmsServlet and TwitterServlet.

Instead what has happened is that people either completely bypassed the Servlet framework, or have built their protocols on top of HTTP.

Of course, if you want to implement a protocol-specific extension for your required protocols, you would have to develop the whole stack - request object, response object, a mechanism of identifying sessions (for example using the MSISDN in an SMS instead of cookies), a templating and rendering framework (equivalent of JSP) - and then build an MVC framework on top of it.