Juggler, driving to his next performance, was stopped by the police. “What are those knives doing in your car?” asked the officer.
“I juggle them in my act.”
“Oh yeah?” says the cop. “Let’s see you do it.”
So the juggler starts tossing and juggling the knives.
A guy driving by sees this and says, “Wow, am I glad I quit drinking. Look at the test they’re making you do now!”

Happy April Fool’s Day!

You make a good point about front end code. It often demands multiple views. When I look at my own user modules, I see 15 public methods that are there simply to provide data to 15 different templates. The multiplicity of different views leads to bulky modules.

In theory, of course, there are other ways of handling things. Fabien Potencier has written about how to handle all static pages with a single method:

http://fabien.potencier.org/article/27/a-symfony-tip-tweak-template-names

But that is for static pages. Dynamic data is more difficult to handle. Here is one area where, initially, it might seem that the web sites built for humans might depart from the needs of an API that is meant only for software robots. But are they really so different?

Richardson and Ruby only request that the verb of a request go in the HTTP headers. They’ve no objections to other parameters being passed through the URL. One might expect to get back a variety of data views, based on the URL parameters, even when the HTTP verb is always GET. And how is that different from a website where a human uses their browser to make a variety of GET requests? I can imagine having a single method to handle all GET requests. At first I worry that such a method would be bloated, but perhaps refactoring could clean it up. The method might be a switch statement, the rest of the code would be in small, protected methods.

I am intrigued by the idea of building a web services layer. How does that work in Symfony? Does it run as one application? Do you mean that the part of your site that faces out to humans only makes API calls? It makes no database calls?

The approach I’ve been taking recently is to always build a web service layer in any database-driven project. The frontend of the site talks only to this layer and never accesses the database directly. You do pay a cost in performance, but has several big advantages:
* Your frontend code becomes much simpler, and it’s much easier to split up the work of building a large website into frontend and backend concerns.
* You have the freedom of changing your frontend technology without big changes on the backend. This has come in handy on some projects when, for instance, we abandoned a Flash frontend in favor of an HTML frontend.
* The web service layer is a natural place to optimize performance using caching, etc.