Tag Archives: api

Posted on
by

I recently set up S/MIME for my email address. While in a day to day sense it is a lot simpler than PGP to use, primarily because native client support is near universal, the set up process was, to say the least, complicated.

By far and away the most complicated part of the process was obtaining the certificate required to sign and encrypt the emails.

Each certificate authority has a different procedure to obtain them; some requiring you to fill out an online form, some requiring a phone conversation (!!!), some would email you a link, others would offer you a direct download. Sometimes the certificate couldn’t be directly used, and would require you to install the certificate into your web browser, and then through some complicated process export them into a format that your email client could use.

S/MIME is mostly deployed within large organisations, so it is likely that it is envisaged that some IT department would take care of generating and installing certificates on a user’s behalf. But, if we want to see it more widely used, we need to streamline this process.

There is, in my mind, no reason why this process can’t be handled in a more streamlined way. Imagine setting up an email account in your mail client, wouldn’t it be cool if the last screen of the wizard prompted you to secure your email address, and gave you a short list of providers to click on? You mail client could then securely communicate with an endpoint, send the email address of the account, and then return and automatically install the generated certificate.

All that needs to happen is for the certificate providers to agree on some sort of protocol to do this, and for one or two email clients to implement it. It is the kind of problem that could be solved by getting a couple of developers from Commodo, Trust, Mozilla and the Microsoft Outlook team in a room for half a day.

How can we make this happen?

Posted on
by

Home.API The modern world is full of cool gizmos, but our houses are pretty primitive by comparison.

Still, more and more houses are getting water and electricity smart meters of one sort or another. Various new home automation, like the Belkin Wemo, are hitting the market, and that is not to mention all the home brew efforts that various hackers are putting together themselves.

As you can see from other posts on this blog, I’ve been having a bit of fun playing around my Current Cost smart electricity meter, as well as playing around with the Raspberry Pi and PiFace, which has got me thinking about building a number of appliances around the place to solve a number of real world problems around the house – monitoring and controlling a number of things (I’ll post some more on this later).

So, problem is, all these devices have their own ways of talking to them, reading data and controlling them, and I thought it’d be cool if we had a common and easily extensible API, which you could talk to using standard web technologies. Having such a platform would enable people to start wiring things together in unexpected ways, using a variety of different devices, the more apis get added the more possibilities you have!

Introducing Home.API

Hacked together as an itch-scratching weekend project, Home.API is my first stab at solving the problem. It is a PHP 5.3+ web app that runs on a web server and is designed to be easily extensible through simple plugins and human readable configuration files.

Out of the box it includes a couple of demo plugins, and a simple dashboard, although the real power comes from its extensible JSON API which can be accessed by simple web calls.

Key features

  • Simple plugin format and configuration files.
  • Wire up the API in a branch structure which suits, use each plugin multiple times.
  • Simple but powerful development dashboard.
  • Currently a JSON API, but trivial to extend to other output formats using a powerful template system.

Format of an endpoint definition file

You API is defined using one or more configuration files in the /def directory. The configuration file contains a number of entries, separated by blank lines, each one defines the endpoint, class to use, and any initialisation parameters.

E.g.

/bedroom/light
    class \x10\DimmerLight
    minvalue 0
    maxvalue 50
    deviceIP 192.168.0.45

/hallway/light
    class \x10\DimmerLight
    minvalue 0
    maxvalue 100
    deviceIP 192.168.0.46

Making a call

Making an API call is simply a matter of making a call to a URL http://my.home.api/api/your/endpoint/function.format?param1=xxxx¶m2=yyyy, where function.format is the exposed method of the plugin class, and format is the template to use (e.g. json).

Each of these endpoints can act independently, and in our example you might be able to execute commands like:

http://home.local/api/bedroom/light/currentLevel.json

or

http://home.local/api/bedroom/light/setting.json?level=20

or

http://home.local/api/hallway/light/off.json

Have a play, and let me know what you think!

» Visit the project on Github…

Posted on
by

As I’ve blogged before, IFTTT.com (short for “If This Then That”) is a popular service which lets you trigger actions based on certain events that occur around the internet.

One of the most requested features, by programmers at least, is to add WebHooks support. Webhooks are a very simple way of pinging API information about the internet between web services. It uses JSON to send an arbitrary payload over HTTP via a POST request to a specified endpoint. This is about as simple as you can get, which is of course the beauty of it.

Support for Webhooks is an obvious extension to IFTTT, and would allow people to build on the service, connecting together more than just the hand picked menu of channels on the IFTTT dashboard. Quite why this is so slow coming is a mystery; some have speculated that it was a business decision on their part, others that it is hard to build a slick interface for something of such a highly technical nature, others that they simply haven’t gotten around to it just yet.

Free Software to the Rescue!

Until IFTTT implement a WebHooks channel, you can use the following workaround.

Abhay Rana, in a project over on GitHub, has built a some code which provides a WebHooks bridge for IFTTT and other services. I have extend to add some extra functionality you might find useful.

Currently, the IFTTT wordpress channel uses that software’s RPC endpoint to make posts, so the software works by providing a little bit of middleware, that you install on an internet facing machine, which pretends to be an installation of WordPress. You then point the wordpress IFTTT channel at this installation, passing it some special parameters.

You specify the final endpoint URL as a tag, and by default the contents of the post, title, and categories get JSON encoded and relayed to this endpoint.

My extensions

Different Webhook endpoints need different fields, however, so my extension lets you provide service specific plugins. These plugins can manipulate the data sent to the upstream endpoint further, providing different fields and encoding options. This lets you support multiple webhook endpoints from a single installation, and without having to set up multiple IFTTT accounts.

To use, create the appropriate plugin in your installation’s plugins directory containing your extension of the Plugin class, then pass a special category “plugin:NameOfClass“.

I have included an example class and a JSON payload class. The latter assumes that the post body is valid JSON, validates it, and then sends it to the upstream endpoint. This lets you send specially crafted messages to upstream webhook endpoints.

My extension also includes much more debug logging, as well as some extra validation code and graceful failures.

Why?

IFTTT is a fantastically useful service, but unfortunately you are limited to using the services they choose to (or have time to) write connectors for. I find this limiting, and at times frustrating, since as well as excluding some great existing services, it places limits on my ability to hack my own stuff together!

Previously, I’d often used twitter to glue things together. However, since Twitter are currently making concerted efforts to turn their service into just another ad serving platform, rather than the communication platform and messaging service it was growing into, it was necessary to come up with an alternative method.

WebHooks seem a better solution anyway.

Thanks again to Abhay Rana for the original code, and I hope people find my additions useful!

» Visit the project on Github…