I’ve been building websites for almost 10 years now and recently I had the chance to work in a team where we can investigate about new technologies, patterns, etc.
While we are building an application which has be be compliant with multiple platforms, we have to use webservices to provide data and services to third party application such as a flash interface or a mobile application for exemple.

After few weeks building the frontend to administrate the data from the database, we decided to do something similar that what’s doing battlelog.battlefield.com. Basically battlelog offer a very fluid interface using javascript and webservices. If you navigate through the website all the templates are loaded using javascript. The route is defined by the URI. If you have already used backbone.js, a javascript framework (one of the most famous I think) you’ll know that the routes are defined in the URI using # (hash) and the route of the view you want to call. You end up with the following http://www.mysite.com/admin#admin/user/create. Using HTML pushState() you can update the URI of the browser (if this one support HTML5) so you’ll get this kind of clean URI: http://www.mysite.com/admin/user/create.

The advantage to this is that if you reload the page you’ll end up asking the server to render the template. The server side is requesting data needed to render the template correctly and render it (server side). So basically what battlelog is doing is rendering the same template, once using webservices through Ajax request using a javascript framework, and once using the server side controller getting the needed data and rendering the template. For everyone using battlelog, you have to say that it’s pretty fast and fluid.

If you think about it, you need the exact same data on the server side and javascript side to render your template. So now, why not using the same webservice on the server side and client side? YES, is the answer. Webservice IS the Answer. We can imagine a kind of routing system that would be used by both the javascript side and the server side. The route definition would be a bit more detailed than a normal route definition. For example we could have something similar to this JSON sample: 

"Control/User/Create": {
    "privilege": ["ROLE_A", "ROLE_B"],
    "required":[],
    "defaults":[],
    "jsRoute": "control/user/create",
    "data":[
        {
        "api": "/webservice/user/getAvailableRoles",
        "var": "availableRoles"
        },
        {
        "api": "/webservice/user/getAvailableJobs",
        "var": "availableJobs"
        }
    ],
    "template": "Control/User/Create.html.twig"
}

I might forget stuff here but the idea is here. On the server side, a factory is calling the webservices, checking the privileges and rendering the template injecting the data returned by the webservices. The up side, no more controller on the server side. You want to create a new page, using a new template, just create an entry in the JSON file specifying the template and the webservices you need to call and done!

The javascript side is a bit more complex because you need to bind events but still very easy to implement. When we bootstrap the application we need to setup all the JS routes that are defined into the JSON file and configure each route specifying which webservice we need to call, etc.

So as you can see, the whole application is based on API calls. What does this mean? It means a lot of stuff, let’s list them:

  • Designer can build pages without having to touch the server side (PHP in our case)
  • You can easily build a new application using the API (everything is here)
  • If there is a problem on the server side, it’s coming from the API (easy to find)
  • We can manage privileges per API very easily, even provide a control panel for it.

Feel free to comment on this idea, but for me and the team I’m working with, this is the future of web application. Web application API driven.