On Tue, Sep 14, 2010 at 4:31 PM, Alim <[email protected]> wrote: > > @ Dennis > I think a front controller that supports both MVC and REST > is more likely to be a strong controller. A good example is Spring 3 > (www.springsource.org) which is now supporting RESTful service and MVC > as well.
Interesting; I hadn't looked into Spring MVC before. From what I've seen so far its design appears to differ considerably from Model-Glue. Spring MVC seems to have a "one controller per request" design which puts it closer to ColdBox and FW/1. Model-Glue instead uses a event queue model where requests are routed through multiple event handlers which may invoke multiple controllers. REST favours "one controller per request" designs as it makes it easier to map URIs to entities. A ColdFusion framework that *does* have a lot in common with Java Spring is ColdSpring 2.0. I can definitely see how ColdSpring 2.0 could be used as the basis for a REST front controller. Keep in mind though that ColdSpring 2.0 is a serious work-in-progress by Mark Mandel and is not yet deemed production-ready as a bean factory. I haven't started digging into ColdSpring 2.0 yet but if/when I do I'll think about how it might be used for REST. I'd expect to see ColdSpring support REST long before Model-Glue does. It is the client asking for RESTfull services. What does your client think "RESTful services" means? What level of "RESTful" is sufficient for your client? There are no official rules for deciding whether a Web API is "RESTful", but I find the Richardson Maturity Model <http://martinfowler.com/articles/richardsonMaturityModel.html> quite helpful when thinking about this. Note that a large number of Web APIs that call themselves "RESTful" are only at Level 0 in this model. A Model-Glue application with SES URL support activated can implement "Level 0 REST" without any extensions to the framework. > In our case we > have build our whole application on model-glue. Just because of > providing RESTful service switching to another controller seems to be > painful for system integrity. > I'm curious about what logic you are doing in your Model-Glue controllers that is still needed in a REST API. Security is the only type of logic that I've found in my applications that fits that criteria, but perhaps my application isn't complex enough. I'm open to hear about other use cases ... anyone? Soap is already supported inside model-glue then why not REST? > Comparing SOAP and REST is like comparing apples and oranges. SOAP is a RPC protocol, while REST is an API architecture. The RemotingService.cfc that provides SOAP and AMF interfaces for Model-Glue simply takes an event name and value collection and converts them into a Model-Glue event, then fires up the framework's request cycle. It's not terribly different from the regular HTML/HTTP request cycle. As I mentioned earlier, REST has a very different way of looking at requests which does not match well with the event queue model for Model-Glue. I'd love to hear of any ideas on how to narrow this conceptual gap. P.S. I apologize if I sound overly critical. I agree that REST is an important technology for Web application development; however I don't want Model-Glue to become a "kitchen sink" framework and I don't think REST is a good fit for it. Cheers, -- Dennis -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en
