I would think that simplifying the nature of templates and endpoints alike allows a development team to place more focus on interactivity on the XForms/client-side. My experience has been that separation of concerns, at least as far as Spring is concerned in a typical Java control architecture, results in complexity rather than simplicity.

Using the word “endpoint” is good too – communication endpoints had a meaning before SOA took over the term. I suppose one of the hurdles people often encounter with REST as a concept is that it doesn’t actually mean you can do everything and anything you want with a URL. Defining a collection of endpoints helps to alleviate this approach.

“Template” has the added advantage that it is immediately grokkable by the PHP community.

I might argue that the XForms architecture lends itself to leaving the presentation to XForms / HTML and having XQuery only manipulate the DB or incoming XML. Not only do I think this lets you organize the XQuery in a meaningful way on the server you can serve the View (Xforms / HTML) from a different folder then the controller. Therebey several views associated with a certain controller, and a cleaner organization, something that I might be useful for an admin / user style app where a large portion of the functionality might be shared?