It's been four weeks since the GSoC 2014 results were declared. I was selected by Inclusive Design Institute for developing a public API for their project, ATutor. I had worked with them last year in the GSoC too and my last year mentor, Alexey Novak, was going to mentor me yet again.
Four weeks of community bonding time is a long time and I have utilized this time in discussing the future strategies with my mentor. We had quite a few things to decide because we wanted a good API at the end of the summer. For reference, we took the examples of GitHub and Amara APIs.
Creating a module
We decided that although we would separate the API code from the rest of the ATutor code, we wanted to let the admin have the choice of whether to enable the API. The best way to do it within ATutor was to create a module (BTW, I really dislike reading documentation). If the module was not activated and someone was trying to access the API, we would just show them a message that the feature is disabled.
Choosing a web router class
ATutor is written in core PHP. True that there are a lot of functions within ATutor that do most of the heavy lifting, but it still remains in core PHP. Up until now, there was no need to develop a routing class. However, an API would need a router (unless you plan to create separate directories and pages for each function).
We narrowed down certain options, but finally decided to go with Toro. Although people call it a 'micro framework', the source just consists of a file with 120 odd lines. It was just perfect to add to ATutor. Toro is also designed specifically for creating a REST framework. To top it all, the 'Hello World' function is so simple, yet elegant.
<?php
class MainHandler {
function get() {
echo "Hello, world";
}
}
Toro::serve(array(
"/" => "MainHandler",
));
An important thing to note is that Toro does the routing, but the structure of the app is largely dependent on the developer. Having worked with Django so much, I decided to go with the flow. I split the core API into individual apps, each with their own urls.php and router_classes.php, which contains the routes and the handlers, respectively. Have a look at it here.
Making the list
Lastly, there remained one uphill task before I could start coding (Yeah, I hadn't started already!) I had to create a list of possible API calls that I would implement, with details of what parameters would be passed on with each request and what would be returned. The user access levels were to be decided later, once we moved on to implementing the user authentication. I have come up with a preliminary list of GET, POST, PUT and DELETE calls, and I can start coding (finally) once it is verified by my mentor.
The official coding begins in two more days, and it's going to be real fun, much like last year. Looking forward to crafting some mean looking code.