I got bored one evening, so I hacked together the beginnings of an API library for latakoo Flight. Currently it’s available in three four tasty flavours – PHP, Python, Ruby and C# .NET / Mono.

The libraries are minimal but functional; they let you perform both anonymous and authenticated queries against the latakoo API endpoint, but I’ve only had time to add method wrappers for a few of api calls. Feel free to fork the project to help flesh these out!

Hopefully these libraries will make it easier to get the power of latakoo behind your project.

Happy hacking!

» API Documentation
» Github Project Page

I like feeds and APIs.

Feeds and APIs provide ways for others to access a service and to recombine the data in new and unexpected ways. Ways that have consistently been proven to be beneficial to both parties (which makes google’s increasing antipathy towards them an interesting, not to mention short sighted, trend).

Anyway, it was one morning when I was attempting to find a route to work for my girlfriend which bypassed the numerous arterial route crashes that had happened that morning and I found myself pondering thus…

… wouldn’t it be cool if roads and junctions had permanent URLs, and better yet if you could get a data feed on them?

This would let you do many cool things, for example you could enter your route to work and get a status of the traffic en route – or at the very least attach a particular traffic blackspot (in our case the 13 bends of death on the A4074) to ifttt and get SMS alerts if there was a problem.

Giving roads and junctions addressable urls would be an obvious extension to the google maps API, but given that Google won’t even let you embed a map in a page if it contains a traffic data overlay it seems unlikely they’ll provide such access to their data. Other sources such as the Yahoo’s traffic API has long since been shut down.

So, what alternative traffic data sources could we use?

One possible data source we could use would be to parse a twitter search for the road in question. We both currently use ifttt hookups to get alerts for certain key roads, so the basic concept is sound.

This isn’t perfect, for example there is no understanding of the context of a message – so for example a message saying “No traffic problems on the A4074″ and “Terrible crash on the A4074″ would both trigger the alert, but only the latter would indicate a problem.

The other problem of course is that it also relies on people tweeting, but in effect this would actually pull in quite a diverse range of secondary sources – in my case, for example, it also pulls in any source that feed into the local radio station – which includes reports from their traffic spotter plane.

As an individual without access to data from traffic sensors, or any ability to collect data directly (unlike, say, google who can use position reports from android phones), we are pretty much limited to collecting data from secondary sources as far as I can see.

What other sources could we use?

Another one of Elgg‘s less documented but very powerful features is the ability to expose functionality from the core and user modules in a standard way via a REST like API.

This gives you the opportunity to develop interoperable web services and provide them to the users of your site, all in a standardised way.

The endpoint

To make an API call you must direct your query at a special URL. This query will be either a GET or a POST query (depending on the command you are executing), the specific endpoint you use depends on the format you want the return value returned in.

The endpoint:

http://yoursite.com/pg/api/[protocol]/[return format]/

Where:

• [protocol] is the protocol being used, in this case and for the moment only “rest” is supported.
• [return format] is the format you want your information returned in, either “php”, “json” or “xml”.

This endpoint should then be passed the method and any parameters as GET variables, so for example:

http://yoursite.com/pg/api/rest/xml/?method=test.test&myparam=foo&anotherparam=bar

Would pass “foo” and “bar” as the given named parameters to the function “test.test” and return the result in XML format.

Notice here also that the API uses the “PG” page handler extension, this means that it would be a relatively simple matter to add a new API protocol or replace the entire API subsystem in a module – should you be so inclined.

Return result

The result of the api call will be an entity encoded in your chosen format.

This entity will have a “status” parameter – zero for success, non-zero denotes an error. Result data will be in the “result” parameter. You may also receive some messages and debug information.

Exporting a function

Any Elgg function – core or module – can be exposed via the API, all you have to do is declare it using expose_function() from within your code, passing the method name, handler and any parameters (note that these parameters must be declared in the same order as they appear in your function).

Listing functions

You can see a list of all registered functions using the built in api command “system.api.list”, this is also a useful test to see if your client is configured correctly.

E.g.

http://yoursite.com/pg/api/rest/xml/?method=system.api.list

Authorising and authenticating

Most commands will require some form of authorisation in order to function. There are two main types of authorisation – protocol level which determines whether a given client is permitted to connect, and user level where a command whereby a user requires a special token in lieu of a username and password.

Protocol level authentication
Protocol level authentication is a way to ensure that commands only come from approved clients for which you have previously given keys. This is in keeping with many web based API systems and permits you to disconnect clients who abuse your system, or track usage for accountancy purposes.

The client must send a HMAC signature together with a set of special HTTP headers when making a call. This ensures that the API call is being made from the stated client and that the data has not been tampered with.

Eagle-eyed readers with long memories will see a lot of similarity with the ElggVoices API I wrote about previously.

The HMAC must be constructed over the following data:

• The Secret Key provided by the target Elgg install (as provided easily by the APIAdmin plugin).
• The current unix time in microseconds as a floating point decimal, produced my microtime(true).
• Your API key identifying you to the Elgg api server (companion to your secret key).
• URLEncoded string representation of any GET variable parameters, eg “method=test.test&foo=bar”
• If you are sending post data, the hash of this data.

Some extra information must be added to the HTTP header in order for this data to be correctly processed:

• X-Elgg-apikey – The API key (not the secret key!)
• X-Elgg-time – Microtime used in the HMAC calculation
• X-Elgg-hmac – The HMAC as hex characters.
• X-Elgg-hmac-algo – The algorithm used in the HMAC calculation – eg, sha1, md5 etc

If you are sending POST data you must also send:

• X-Elgg-posthash – The hash of the POST data.
• X-Elgg-posthash-algo – The algorithm used to produce the POST data hash – eg, md5.
• Content-type – The content type of the data you are sending (if in doubt use application/octet-stream).
• Content-Length – The length in bytes of your POST data.

Much of this will be handled for you if you use the built in Elgg API Client.

User level tokens

User level tokens are used to identify a specific user on the target system, in much the same way as if they were to log in with their user name and password, but without the need to send this for every API call.

Tokens are time limited, and so it will be necessary for your client to periodically refresh the token they use to identify the user.

Tokens are generated by using the API command “auth.gettoken” and passing the username and password as parameters, eg:

http://yoursite.com/pg/api/rest/xml/?method=auth.gettoken&username=foo&password=bar

Anonymous methods
Anonymous methods (such as “system.api.list”) can be executed without any form of authentication, thus accepting connections from any client and regardless of whether they provide a user token. This is useful in certain situations and it goes without saying that you don’t expose sensitive functionality this way.

To do so set $anonymous=true in your call to expose_function().

Image “In UR Reality” by XKCD