API First

An Application Programming Interface is a way for software components to communicate. A web API is a way for a HTTP server to exchange data with Apps, web browsers, and other clients. Roy Fielding described RESTful Web APIs in his doctoral dissertation.

For example, Twitter offers an API that lets developers build iPhone Apps, tweet embedding, integration with 3rd party Apps, and an SMS bridge.

Wikipedia lists the technical reasons why you should build a RESTful API for your App:

There are also many product and business reasons why you should be build an API alongside your App.

BizDev 2.0

Several companies – probably more than a dozen – have approached us to provide printing services for Flickr users, and while we were unable to respond to most of them, given the number of similar requests and other things eating up our time, one company, QOOP, just went ahead and applied for a Commercial API key, which was approved almost immediately, and built a fully-fleshed out service. Then after the fact, business development on our side got in touch, worked out a deal – and the site was built and taking orders while their competitors were still waiting for us to return their emails.

A web API is a scalable way to build out a business development organization. It automates many technical integration details for partners. Caterina Fake called the API program that they ran at Flickr as BizDev 2.0.

It takes less manpower to integrate with partners and humans can deal with more strategic, higher-level issues.

Platforms

A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product. – Steve Yegge

Steve Yegge wrote a long rant about how Amazon understands platforms and how Google does not. Building a platform lets others fill in the missing gaps that you cannot get to.

Google+ does not expose a robust API. Google Hangouts is an excellent feature but the rest of Google+ is damn near useless. A 3rd party developer could build something like Hubot for work collaboration if Google+ exposed an API and extract more value out of Google+.

Different people require different workflows to execute their daily tasks. This is where your API helps them solve their problems.

Network Effects

Large networks of engaged users, differentiated through user experience, and defensible through network effects.

The most important bit is that platforms help you capture network effects. Network effects is one of the few defensible assets on the modern internet.

A network requires connections. An App can connect people. An API can connect Apps. The value of a network increases as more people connect. The value of a network also increases as more Apps connect to it.

Multi Device

The future will consist of many more clients than today. The data from your platform needs to be rendered on desktop browsers, mobile browsers, mobile Apps, partner websites, etc. In the future, your platform will need to read and write data to wearable devices and devices that fall under the umbrella of the Internet of Things.

This future is much closer than we probably think.

Client-side rendering is gaining much more traction for desktop and mobile browsers. This technique consists of sending the data over the network as JSON and then generating HTML on the client using Javascript. A server that exposes an API is required for this technique.

Tools and Documentation

Apigee has done a fantastic job with their API Best Practices documentation. I recommend reading their Web API Design Guide first.

A new tool that I have been using is Apiary. It takes Markdown/Telnet style API description and creates documentation, a server mock, and tests. It is a brilliant tool.