I have been building Joomla extensions since v1 but I soon need to take an API live that I have built and have been using for a while. Currently I am using Joomla 2.5 and have written plugins for this system:


Before going live I would like to future proof the system as much as possible. This API component has only recently started to be upgraded to work with Joomla v3 so it is currently preventing the site from being upgraded. I also think separating the public API and the user portal makes sense as there is no benefit from it being an integrated extension as the API will be used by mobile apps.

The current plan is to rebuild the API on a subdomain which will allow us to upgrade the user portal. I have been reading about the new Joomla framework which looks exciting. Would this be suitable for building a RESTful API for our mobile apps? If so, are they tips on getting started? I've read that FoF can be used to build an API, would this be a good choice? I saw the Kickstarter project intending to build exactly this sort of API, is that a potential option? Should I just strip back the current 2.5 site for the subdomain so it only runs the API?

Any suggestions on the best approach for building a Joomla based RESTful API for mobile interaction will be much appreciated.


4 Answers 4


From my experience:

About Joomla framework

I tried to build a simple RESTful API for integrated authentication based on Joomla framework. It's fairly complex, quite different than the current Joomla API. Also, current source code can't be copy-pasted, and libraries may return unexpected results (being executed in a different environment). I'm going to wait until more code is available, and it has greater adoption.

About FOF framework

I'm currently developing only with FOF. Quite handy, a lot of RAD, automatic configutation, etc; and code is compatible with J2.5/J3.

For a RESTful API, you can just grab the todo-fof-example, and add a controller with the API. Example:

public function getIndexStatus()
    // CSRF prevention
    if ($this->csrfProtection)

    $message['status'] = true;
    $message['error_message'] = 'Status Ok';

    $message = json_encode($message);
    echo $message;



Also, you can take advantage of automatic json views E.g. a browsing view (default.php) can generate json output (just adding default_json.php and echo json_encode ...)

  • 1
    The only problem with FOF as I understand it, is that it is no longer supported by the developer in the Joomla core… although I understand the a version of FOF has been re-forked and is going ahead, just not as part of Joomla?
    – Craig
    Commented May 12, 2014 at 23:27
  • You are right, but it's not an issue at all. Joomla's FOF is pretty stable (I haven't upgraded my extensions yet). New F0F has to be installed as a new library (... at the end you have to always install it in J2.5... and the installer is ready for J3). Right now, 99% of the source code hans't changed.
    – Anibal
    Commented May 12, 2014 at 23:50
  • Thanks for your suggestions, I agree that the Joomla Framework is quite complex but I'm enjoying learning how to use it. I wanted to try using the framework for my API as is quite simple but can't get it to return the correct header for JSON. I started another question about it.
    – Joe P
    Commented Jun 4, 2014 at 17:18

com_api is definitely a good way to build REST services for your site if the extension itself is not based on FOF/RAD. However be careful with a few gotchas if you plan to create a separate Joomla instance only for the API

  • Domain specific stuff (Eg: If you are supporting user registration, then the welcome email would include a link to the API subdomain). This could be mitigated by playing around with the PHP server variable.
  • Similarly image paths etc need to be correct, unless you are using S3

Apart from that I'm sure there should not be any problems, since that will continue to be developed till there is a de-facto Joomla way of creating APIs.

Disclaimer : I am the maintainer of https://github.com/techjoomla/com_api

  • Thanks for your answer, it's great to know that you are continuing to develop it. I love how com_api works but I wanted to try and avoid running the entire Joomla CMS just to provide an API. If I can't get the framework to work as I need, I will definitely continue to use this.
    – Joe P
    Commented Jun 4, 2014 at 17:24

My two cents:

For a customer I needed to access the contents of his joomla site from a smartphone app. The contents were placed in com_content so initially I used obRSS feeds. Then I found jBackend on JED and tried it. It is available here http://www.selfget.com/products/jbackend.html The code seems very clean and it supports RESTful requests and JSON responses. Online documentation is limited but clear enough for technicians. Unfortunately at the moment it only supports com_user and com_content but in my case this was fine. Now I should use it for another customer who uses K2 CCK. I'm trying to build a custom plugin to access K2 articles and categories, but at least I will save the entire requests management code. I sent an email to developer and he told me he are working on additional modules like K2 and Kunena forum too, it is very promising extension.


The following site seems to be an excellent resource for guidelines on how to build a RESTful JSON API:


For what it's worth, I am also launching an API product for Joomla 3.4.x called cAPI http://getcapi.org.

The primary differentiator here is that I staked my routing framework on Slim micro-framework. This allows me to incorporate an already tried and tested, robust framework into the Joomla application instance. I have also create a plugin architecture for the service routes, opening the door for add-ons and web services security.

You can find additional information from other posts, here:


Let me know if you have any questions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.