What would be involved in creating a RESTful API for Joomla? (move away from XML-RPC)

The idea wouldn't necessarily be to have full control/functionality out of the box but maybe allow for basic features and with 3rd party devs in mind. Developers could include something in their extension that interfaces with the core RESTful api so they can have API access as well.

i.e. http://yoururl.com/index.php?option=com_api&token=12345extensio...

sample response:

<?xml version="1.0" encoding="UTF-8"?>
<category>
<id>11</id>
<name><![CDATA[Your Product]]></name>
<description><![CDATA[<p>This is overview of a category</p>
]]></description>
<thumb>http://yoursite/images/image.jpg</thumb>
</category>

etc.....

What are your thoughts?

Views: 846

Tags: API, Joomla

Mitch Pirtle Comment by Mitch Pirtle on November 11, 2009 at 1:26pm
Joomla providing a RESTful service API would be awesome, especially when you consider federated content and user sources.

I just built a very high-performance commerce platform that was using RESTful interfaces for authentication, registration, payment authorization. It really is the only way to scale something to insane extremes, as that allows you to tackle each REST service separately instead of one gigantic mess.

I also wrote a JRestRequest library and am wondering if anyone else would find it useful?
Rick Blalock Comment by Rick Blalock on November 11, 2009 at 1:27pm
Oh Yeh? I'm interested.........
David Vega Comment by David Vega on November 12, 2009 at 4:07am
Heh, interestingly I was just working on this for a university project where I am getting some inspiration on the J! framework to make an HMVC framework that supports distribution natively.

Anyhow, I am integrating REST into my Request object that is somewhat similar to Joomla's in the sense that it lets you manipulate the environment hashes, but in addition when building the object as an instance with the URL you can actually send the request and get a response back.

I based the implementation on this: http://www.sematopia.com/2006/10/how-to-making-a-php-rest-client-to..., but requires a pear package, so I will now be moving the implementation to cURL and might even add file support.
Amy Stephen Comment by Amy Stephen on November 12, 2009 at 2:45pm
Nice post, Rick. Yes, Mitch! Cool, David!

All good things here.
Rick Blalock Comment by Rick Blalock on November 12, 2009 at 2:48pm
Yeh Mitch...I'd love to see the JRestRequest and how you've been using it.
Rick Blalock Comment by Rick Blalock on November 27, 2009 at 6:35am
Just did a quick draft component trying out the idea.

"&extension=" would be for 3PD integration or the core. Example below is the core in the URL. The idea for 3PD is they would put a specific folder in their component with their API setup, format, etc. (another controller) that the RESTful component looks through and spits out what's needed.
"&call=" Would be the method calls / paths. The example below would be an article with an ID of 11.
"&format=" JSON or XML output

i.e. This:
index.php?option=com_api&extension=core&call=article/11&format=json

Outputs (in JSON format):
[{"id":"11","title":"How do I upgrade to Joomla! 1.5 ?","alias":"how-do-i-upgrade-to-joomla-15",....etc.

So now the question is, what's the best way to do the authentication? You can manually pass an ID or a username to the user object, which means an API call can pass the username to the user object. Then I guess it can be checked with a password that would have to be passed as well. I'm not a security expert but I have a nagging feeling it isn't the best route. Also, something to keep in mind...you can pass the username OR the user ID to the user object...which kind of worries me opening that up to an api call.

What about user tokens? The RESTful component could store a user token for each user. That or the admin can generate a token for each user on request.

I guess down the road I should consider application authorization too but for right now I'm just thinking through how individuals on a J! site trying to access the API for any given reason (for instance, if a JomSocial setup used it on a site).
Rick Blalock Comment by Rick Blalock on November 29, 2009 at 7:40am
@Livingstone - Thanks for the great response. Very helpful insight.

I think you're right, the easiest thing to do is have a table with the token/secret word. And for whichever user needs a token, the admin can assign it.

My thinking is that there needs to be some easy interface for 3PD extensions to use it as well. So, for instance, JomSocial could use it by creating a folder with their api in it. They could tie in to the api component to handle all the requests, etc. and they would just have to worry about the return data in JSON/XML.

...just ideas at this point.
Amy Stephen Comment by Amy Stephen on November 29, 2009 at 2:40pm
Wanted to add Louis's post for how to very simply return JSON formatted content from a Joomla! component.

Also, Joe LeBlanc shared a starter REST Component on the Joomla! General Dev list that might be helpful.
Mitch Pirtle Comment by Mitch Pirtle on November 29, 2009 at 3:48pm
Ok, if we're considering creating an API extension for Joomla, I'd suggest a driver approach, and getting 3PDs involved in the design/implementation in the hopes of setting a standard.

At first I like each extension doing their own thing, however keeping API access locked down to one extension does make a lot of things far simpler.

Maybe we could set a standard coding style for extensions, and expose an API for calling those methods through an API extension? That way you could honor authentication and ACL, and also implement any custom token based systems in one place.
Rick Blalock Comment by Rick Blalock on November 29, 2009 at 9:07pm
@Amy: Thanks for the reference from Louis's post. Helps with how to handle the views actually. I'm going to try to get Joe to collaborate on here, see what his thoughts are.

@Mitch:
I agree with getting 3PD devs in on it as I feel the success for something like this is dependent on an easy way for them to interface with a main API component.

I think that the main "api component" can handle all core Joomla stuff and then offer a wrapper class or something similar for 3PD. So, in essence, they have available to them "tools" that the api component provides while having complete control over their own output and api functionality within their extension.

Here are some ideas off the top of my head (hence some vagueness):

3PD INTEGRATION
'com_api' (i'll call it for now) -> controller detects whether the extension is the core or 3rd party. If 3rd party, the 3PD extension gets passed several things regarding the request: format (i.e. json/xml), method / calls (i.e. /gallery/11...for a gallery id of 11...for some gallery component), passes core ACL info of the user using the API, etc.

This data is passed to a predefined file that all 3PD extensions must have in their file structure (another controller on their end perhaps). Then the 3PD extension has to build out their data structure and return its' formatted data back to com_api.

'com_api'->controller continues with the request and takes returned formatted data from 3PD and passes it to the view.

It'd be nice to somehow inject certain nodes (in the XML format case) into a 3PD data structure, after they return the data, so they don't have to worry about it. (i.e. ACL permissions returned) Not sure how exactly this would work.

ACL WORKFLOW
- Admin creates API access for user, which generates a token for that user. (assuming it's a manual process and a token isn't available for every user).
- Maybe even have some extra options assigned to a user's token (read/write permissions for user when using the API). Might be better to just let Joomla's ACL handle that though...but it could be useful.

ACL Helper class in com_api that checks against user token and authorization / ACL. Maybe have wrapper methods for the User object stuff to make it easier for 3PD devs to use in their api integration. This class could even be extended by 3PD.


Anyway, so these were some initial thoughts. Some is sort of vague as it's off the top of my head. Let me know your thoughts.

I worked on a draft component over the weekend. Going to work some more on it and I'll post it here to keep the ideas flowing.

Really, as I see it, returning the data is really easy (as demonstrated by Amy's reference to Louis's post above)...the hard part is the ACL.

Comment

You need to be a member of All Together, As A Whole to add comments!

Join All Together, As A Whole

Badge

Loading…

© 2012   Created by Amy Stephen.

Badges  |  Report an Issue  |  Terms of Service