Nothing says privacy risk more than an API

Less than a handful of years ago, mention the three letter acronym 'API' to a regular Internet user and you'd have got the look of "stay away from me, you scary unwashed software geek who is about to bore me to tears" (that's the bleeped version of the internal dialog). Now everything has changed. Not only is API part of the regular semi-tech word-dropping of web users, lack of one can raise questions about the viability of a modern web application. A publicly available API is a badge of honor for startup web apps that says "the information we have is worth being consumed by other apps, so its got to be good enough for you too". 

The Application Programming Interface, or API, is the technical Lego brick that lets developers from across the globe plug into an application, to use the data and functionality of the website without the annoying user interface of that website getting in the way. It makes it easy for other applications to see the data that you as a regular logged in user can see, as long as you click the OK button to authorize it to do so. If you can see details of your friends lives, there is a good chance that by authorizing that app by entering your password that app can see the details of your friends lives too.

A well thought out API is not technically the problem. Many APIs recognize that they are a great way to trawl through far more data than could be done by just browsing the website and protect really private stuff effectively. The problem is still that an API can allow a fairly anonymous developer to collect tons of data, process it and store it extremely rapidly. That developer has their very own, possibly limited privacy policy that you as a user of the primary web service have no control over. Your friend who clicked an OK button authorized a developer to access to your data as a proxy of what they could do on the website. You had no say in the matter that a third party app now has access to the data your friend sees on the website.

In the majority of cases the API itself is not the problem. It is what it stands for in terms of the sheer amount of data a web service has. Re-phrasing what I said at the beginning:

"API" says that a web app collects, stores and makes accessible a lot of potentially personal information that any number of third-party applications might find valuable to consume and reuse

The real problem is that in most cases the information web apps have is not original data and a work of exceptional creativity. It is data collected from its users who enjoy sharing details of their lives with their friends and occasional strangers. It is the data stored in LinkedIn, Facebook, Twitter, et al. The data is largely personal and untouched, beyond being transformed in a way that allows it to be retrieved in an instant. When you read "API" on a social networking site, consider this: the website in question probably collects a lot of personal information about its users and their daily habits and actions. Can you trust the developers that tap into your data through the API as much as you trust your friends?

A post from the Improving It blog

Let us help you improve your business today. Visit www.consected.com

You are nothing without a public API

I am going to build an API. Who wants to help me shape it? After all, every self-respecting web 2.0 service has an API. And my self-respecting web 2.0 service wants to be the best platform in the cloud for developers to build super-profitable applications.

For those of you who aren't familiar with the concept of an API on a web-based service (for those of you that are, bear with me) the API is like Lego for geeks - it gives smart developers with a wish to "get rich quick" the opportunity to build out their killer-app, using the building blocks of an application that already has done some of the grunt work for them. This isn't just a way for developers to leach off the hard work of others. Its really about a service being able to bring in smart, innovative individuals, at minimal cost, and in return for the talent and ideas they put into building applications around your service you take much of the mundane stuff out of the picture for them. Innovation can thrive and isn't stifled by maintaining servers, doing backups, or building login and security. And both developers and service providers make sure that there is a way they can make a good healthy profit if one or other sells the new application.

APIs are great if the service that you build on hits one of two criteria:

1. It is so successful that you stand a chance of picking up some of the available market of 50 million people using it
2. It is so useful and makes the development of your applications so much faster that your app can offer real business benefits

As I have been looking at SaaS/cloud-based business process management (BPM) and workflow tools, none seem to offer a truly open API, allowing developers to hack together whatever they need to around the central core to get to the application that they desire. Why is this?

BPM tools have come from the enterprise software school of thought. You install one in house, spend thousands of dollars on training, build an application for a department, then wait for IT and the business to find the budget to repeat. Software as a Service BPM / workflow offerings (Consected is one, although there are a handful of others) take the grunt work out of putting a new workflow system in place. We handle the servers, the backups, security, etc. We also have to make the configuration far easier than our enterprise software grand-parents, as we're not going to be able to attract people with a 10k price tag for training. This can make some of the flexibility at times a little limited...

So this is where the API comes into play. The underlying capabilities of a service such as Consected really help developers build applications faster. Sure, they're probably not building another FriendTweeter, or whatever, but if there is a real business problem out there that they see companies have, and some smart hackers have never really found the tool they want to build it on, this is a great option. SaaS BPM gives a developer this great stuff:

• Workflow - real, structured workflow, tracking work as it flows through a series (possibly very long) of activities performed by people
• Task tracking - allowing simple ad-hoc tasks to be created, delivered to users and tracked through time
• Structure - an obvious way of structuring applications where work or activities performed by one or many people fit together really easily
• Notification - configuration by users of how they want to be informed about work targeted at them
• Search - ensuring that work you create can be found
• Storage - of data, documents and related information
• UI - yeah, you don't necessarily want to have to build all the stuff that's been done before, just build on it
• Security - authentication, authorization, roles, audit, user and password management, etc

Consected has an API today. But I think that it could be better. The underlying service works great, and is fast to build applications on. But developers are what make services in the cloud successful. And how often as a developer do you get to shout out your ideas and have someone put them in place for you, so you can get on with building your killer app?

If you'd like to see how Consected can take the dull work out of your next killer app while giving you the chance to create the API and platform of your dreams to build on, take a look at the website (its a bit corporate, I know), contact me (phil.ayres at consected dot com, twitter.com/consected, etc), leave a comment on the blog, or even pick up the phone and give me a call.

We are open to ideas for us to have fun building applications, get noticed, and hopefully make a bit of money too!

A post from the Improving It blog