This is a guest post by Luke Jones, a young and enthusiastic web designer from the U.K, check out his personal site here, or follow him on Twitter.
Reading The CloudApp Story, I read a comment on the interview which said the following:
‘Building an API might be ‘useful’ but it’s really a question of whether you have the time or resources to do it. Building on practical features often just seems more important.’
Whilst I do understand where he’s coming from, what he said is something I wholeheartedly disagree with. Of course practical features should be the main part of your application, but rather than adding features it is, in my opinion, often more valuable to take the time to develop an API, with a few obvious caveats*.
There’s one group of people who will benefit from having an API available: your users. Without your users you wouldn’t have a popular application and you certainly wouldn’t be able to monetize it, so you should give something back. Providing your users with an API to play around with allows them to dig deeper into your application, exploring it further than ever possible.
These explorations and the results of these explorations will give them the opportunity to expand the application in ways you may not have thought possible, creating features for users that people love, use and grow to need, creating a community of people who love and organically recommend your app — what more could you ask for?
[inline_ad]
An ideal example of a great app that wouldn’t be available were it not for a API is TweetBot, an application that appeared out of nowhere but has quickly grown to become one of the most popular Twitter clients available, regardless of the official Twitter application. This isn’t because the official Twitter app is bad, it’s because the developers of TweetBot have a completely different set of standards and ideas and they’ve spent time creating something completely different to what we’ve seen before.
In conclusion, I think it’s an absolute top priority for any relevant application to have an API available and it’s amazing that startups like CloudApp are taking the time to develop one. Giving users a reason to explore, extend and build a community around your app would be a daft opportunity to miss.
* I’m writing this about an application like CloudApp, if you’ve created an app which will not benefit from an API or of your app has no features then you’re the caveat.
25 Responses
I’m prone to agree with the original commenter, sometimes it does just seem more worthwhile to build on features 95% of users will actually notice, as opposed to an API which 5% of users will notice, and 0.1% of users will actual use to develop.
Look at the Twitter example, 50% of users who use external Twitter clients benefit from the API.
Well that happened eventually, but when twitter was new no body cared about its API.
Yes; but are people not in it for the long run? Confusing argument. Twitter’s API taking time to warm up should be used in support of API development; not in trying to take away from it.
I love the guest columnist post!
Likewise!
Thank you 🙂
Very true, I doubt Twitter would be nearly as successful without an API.
How much time/resources/money does it really take to build an API? Can any developers comment on that?
You would actually build your application around an underlying API, then it’s just a simple matter of configuring and unlocking the API to your users.
What if the developers hadn’t built the application around an API, and wanted to add it on later?
That is a bit more effort. I pretty much create APIs around old code for my living. Many times it might be more cost effective to scrap the internals and use the API. This can be many hundreds of man hours depending on the app.
Writing a consistent API that you later have to respect to not break down your system can be really really hard… If not, everyone would follow the “build API->build software around->profit” path, (once the resistance for coding the API is broken).
Cheers,
Ruben @mostlymaths.net
Thank you for your comment, I think you may’ve misunderstood the article. It’s absolutely paramount that you build the software first and the API comes from this. For an API to have any benefit whatsoever, you need a good product.
Hi Luke, thanks for your answer. I was addressing HUgo’s comment below and Sebastian’s response to it.
Ruben
Ahhh, apologies for that then! The comment wasn’t nested properly.
It was my fault, no need to apologise 😉
I guess it depends. From a developer point of view, we’d first design a private API to handle all the Create/Read/Update/Delete operations on the application data. This is the easy part, it’s code which can be developed and tested in isolation.
To make that API public though, a strong rules system is required so external people can’t mess up your application state. You don’t want your API users to make an infinite number of requests, or let them alter data that doesn’t even belong to them. This is hard because there’s so many things which can go wrong.
that 0.1% has far more leverage than the 95% of users
What I have seen is lack of solid API blocks the growth of a platform. most of the company tries to provide best set of API to engage third party developers , see IPHONE how successful they are in building there AppStore and I am sure one reason for IPhone popularity is great application available in there appstore.
Javin
Top 20 Core Java Interview question
Look at Basecamp. They have a decent API and loads of people plugging into it.
Comments are closed.