At SupportBee we strongly believe in the power of a developer ecosystem. Our API is a step in that direction. However, lately, we have been feeling that a great API is not enough. This post talks about some of our thoughts on this matter.
I am not talking about SOAP APIs are harder to consume than REST APIs or good REST APIs v/s just calling themselves RESTful APIs. Every time you want to consume an API (to create a mashup for instance), you have to create a new app, host it somewhere (may be Heroku), figure out the API authentication (token or oauth) and then write the core logic. As a service provider, even if you are releasing a very well thought out API, most developers will be too bogged down by all this work to experiment with your API. That is why services like IFTTT and Zapier are becoming more and more popular.
The second problem with APIs is versioning. Services evolve over time. New features are rolled out, some features are removed and as a result, APIs change and are versioned over time. As an app developer, you have to continuously keep updating your apps or they stop working. As an API provider, you may see broken apps if the original developers have moved on from the project and you change the API.
The bigger problem with APIs is the kind of apps people can write using it. The apps are often hosted on another domain and your customers have a very fragmented experience when using them. They must often go to 3rd party sites to configure and use apps. Platforms like Facebook are so successful because apps feel very native. To most end users, there is not much difference between a feature made by Facebook and an app running on Facebook.
For many services, apps are often pushing data to other services or pulling data from other services. Basically, the core logic in the app is very simple. These apps are almost like an adapter. Taking data and reformatting it and pushing it forward. This is true for developer services like Github, CRM services like Highrise, Email services like Gmail etc. For such services, a hosted app platform makes a lot of sense.
A good example of a hosted app platform is Github Services. Anyone can write a new service and send Github a pull request. Github can accept the pull request and then run the app in a sandboxed environment. The great thing is that the app is now available to every customer of Github.
Continuing the Github example, there are many benefits to this approach:
There are also some downsides (or rather limitations)
In summary, if you run a service, consider having a hosted app platform. You will make many developers’ life much easier. We would love to hear your thoughts.