I'm on the "What Developers Want" panel at the Business of APIs Conference London, arranged by Mashery. I'm also giving a lightening talk on my take on "What Developers Want".
Unsurprisingly I believe they wany the APIs to offer access to their data in Realtime. Here are the details:
What Makes An API Awesome?
We now have a better idea than ever before what is required to offer an awesome API.
- Our developer portals speak to developers, making it clear what our API offers and how it can benefit them.
- Documentation is well structured, easy to understand and full of lovely code examples
- Our API follow best practices to ensure they can be easily understood, consumed and to building confidence in our solution.
- We offer well maintained API libraries to further speed up the integration of the API using our favourite technologies, to make commonly executed tasks even easier to perform and hide away complexity of some of the more advanced ones.
- We have amazing tooling that not only lets us test how we interact with an API and the responses we get (e.g. io docs) but also provides us with detailed information about how the API interpreted the interaction and exposing the inner workings of our service in relation to the developers functionality
- We are building communities of heroes who champion our product
What more can we offer?
Realtime! Let me explain:
Developers have to make lots of calls to our APIs; make queries to retrieve data, to see if data has changed, to see if new data is available. Take a query as an example: do you have any new information for me?... do you have any new information for me? How about now? Now?
Wouldn't it be great if the instant your API had new or updated information that it was pushed to the developer? You developer has already expressed an interest in data from you by calling your API.
Start thinking about:
- A query to your API isn't always just a one off search or transction. Does is really represent a subscription for data? If so, offer a way of making that call a subscription.
- When new data is created that matches a query push it to them.
- When data that a developer has retrieved changes within your system, push it to them.
- Better yet, give them a way of using that technology directly within their client applications so push data directly to the users of their applications.
How much effort would this save the developer? How much value would this add to your API? How cool would this be for the developer?
So, how can you push this information to your developers?
Realtime Web Technologies
The PubSub Paradigm
In order to push information to developers you need to know that they are interested in that data. The Publish Subscriber pattern makes this possible.
WebHooks
WebHooks offer a way of instantly pushing information from one server to another via a simple HTTP call. Since you have a list of subscribers when you receive new information that matches a subscription or information that a developer is insterested in updates you can push it to a URL. Simple!
HTTP Streaming
HTTP Streaming offers a way of holding a HTTP connection open so that your API can instantly push new information over that existing connection. This is probably an option if your data updates quite frequently.
WebSockets
WebSockets offer a way of maintaining a connection between a server and a client. This lets you instantly push information from the server to the client, but also lets the two instantly communicate in general. WebSockets are an amazing opportunity to API providers for a couple of reasons:
- You can instantly deliver information to any applicaiton that is connected to the web; web apps, mobile apps, networked robots.
- From the point of view from a developer this means they don't need any infrastructure to deal with the delivery of this realtime data. You are providing that for them. This infrastructure can be very real benefit to the developer.
Realtime APIs - I Want Proof
Here are just a few of the many companies who are successfully using Realtime Web Technologies as a core part of their API.
Pusher
Pusher is a hosted WebSockets API so we're delivering this benefit to our customers every day. It's also possible to potentially use Pusher as your WebSockets API. Just a thought!
Twilio
Twilio use WebHooks to let the developer know when an SMS is recieved on a phone number or when there is an incoming call. They also use WebSockets in the Twilio client.
SendGrid
SendGrid use WebHooks as part of their Event & Parse functionality.
DataSift
DataSift offer a HTTP Streaming API so that they can instantly deliver new interactions which meet the criteria you've defined in your DataSift streams.
MailChimp
MailChimp offer WebHooks for a number of events within their system including new subscriptions, unsubscribes, profile changes, email address changes and more.
Twitter have a number of HTTP Streaming API endpoints so that the developer is instantly informed whenever a new tweet is found.
And many more…
Realtime = More Awesome
The technology to let you offer these improved Developer Experiences exist in the form of Realtime Web Technologies. So, start thinking about how you can use them to make things easier for them and take that next step in making your API even more awesome.
